Hi,
I am responding to the first message in this thread because it seems
to be relevant to Java-based extensions.
At 09:59 4-11-2011, Stephan Bergmann wrote:
Hi all,
As already mentioned briefly in my talk at LOCon, we need to make up
our mind how to handle LO extension dependencies.
Each .oxt extension can carry any number of dependencies, specifying
conditions that need to be met by the hosting LO installation for
the extension to be successfully deployable (see
<http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Dependencies>).
This page links to
<http://openoffice.org/extensions/description/2006>, which returns an
ERROR 404, so even if an extension developer wanted to document more
detailed dependencies, they would not know what syntax or elements to
use in their description.xml file.
I was confronted with this problem just today because a new
Java-based extension cannot be installed on some Ubuntu systems even
though it installs without problems on Windows and some other Ubuntu systems.
The extension manager displayed the following error dialog:
(com.sun.star.deployment.DeploymentException) { { Message = "An error
occurred while enabling: accessodf-addon.jar", Context =
(com.sun.star.uno.XInterface) @a403870 }, Cause = (any) {
(com.sun.star.registry.CannotRegisterImplementationException) {{
Message = "", Context = (com.sun.star.uno.XInterface)} @0 } } } }
It turns out that this issue can be solved with
sudo apt-get install libreoffice-java-common
So I thought about how to document that dependency in
description.xml, but I couldn't ... (And libreoffice-java-common or
openoffice.org-java-common may be rather broad.)
Best regards,
Christophe
The mechanism was designed to allow for any number of fine-grained
dependency specifications ("this extension requires availability of
com.sun.star.whatever.Service"), but only a coarse-grained
OpenOffice.org-minimal-version ever got defined (and also a
maximal-version one). After all, it is hard (or at least tedious)
for extension developers to come up with a precise list of features
they depend on, which would be needed to specify a precise list of
fine-grained dependencies. A single minimal-version dependency
appeared so much easier to use.
The OpenOffice.org-minimal-version dependency worked fine as long as
OOo was the de-facto standard, with derivatives tracking OOo
development rather closely and producing new versions in sync with
upstream OOo. The minimal-version dependency's version value was to
be interpreted as the version of the underlying OOo reference
version, so even if a derivative used a different versioning scheme
everything worked out. An extension developed for one product could
also be deployed in a different one (at least in theory; of course
there are always minor glitches that spoil the picture).
Now, LO and OOo (now AOOo) are no longer in such close relation. LO
is heading towards its version 3.5 already while AOOo did not yet
publish its version 3.4, and new features are routinely added to LO
that are unlikely to be included into AOOo. This leads to the following items:
** How shall LO handle the OpenOffice.org-minimal-version dependency?
Strictly speaking, LO 3.4/3.5 should still check against an
OpenOffice.org-minimal-version value of 3.3, as that's the latest
available (A)OOo version. However, for LO 3.4, this check has
(probably accidentally) been changed to "3.4" (and with the current
code towards LO 3.5 it has yet again changed to "3.5"). I would
argue to leave it at "3.4" for both LO 3.4 and LO 3.5. (For one, it
can obviously no longer be changed back to "3.3" for LO 3.4, and
changing it back to "3.3" for LO 3.5 would probably cause more
confusion than its worth. For another, semantically the check will
likely be more-or-less correct, matching the features an AOOo 3.4
will presumably come out with.) If no one objects, I will adapt LO
3.5 so that it still checks for "3.4," not "3.5."
In the future, when AOOo releases new versions after AOOo 3.4, we
would need to check whether it semantically makes sense for LO to
bump its OpenOffice.org-minimal-version check (i.e., whether the
features of that new AOOo version are also available in LO).
** How to specify dependencies for newly introduced LO features?
One option would be to add an additional LibreOffice-minimal-version
dependency. Another option would be to actually make use of
fine-grained dependencies and introduce them as needed (i.e.,
whenever an extension developer wants to make use of a new LO
feature, a corresponding dependency would have to be added).
The former has as pro its ease of use. The latter has as pro that
it shows a way out of the problems caused by
OpenOffice.org-minimal-version and for an opportunity of continued
sharing of extensions across products: If each extension only lists
the features it requires, regardless of any product's version
numbers, it becomes much easier to match that extension against a
given product's capabilities, regardless of brand.
I'd tend to give the fine-grained dependencies a try. That would
require cooperation from extension developers (they would need to
voice their demand for dependencies for specific features, and they
would need to make accurate use of those dependencies in their
extensions). To achieve cross-product extension compatibility, it
would also require some sort of advertising of LO's newly introduced
fine-grained dependencies (so that other products---where
possible---would pick them up together with the corresponding
features), but we would need a place to document any newly
introduced dependencies, anyway.
What do other people think here?
** What happens when LO 4 becomes incompatible?
In that case, any OpenOffice.org-minimal-version dependency,
regardless of version value, should be considered as not satisfied
by LO 4. Similarly, if we did introduce a
LibreOffice.org-minimal-version dependency, any version value of
that dependency less than 4 should be considered as not
satisfied. On the other hand, treatment of any fine-grained
dependencies would have to be handled on a case-by-case basis.
Stephan
--
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Twitter: @RabelaisA11y
---
Open source for accessibility: results from the AEGIS project
www.aegis-project.eu
---
Please don't invite me to Facebook, Quechup or other "social
networks". You may have agreed to their "privacy policy", but I haven't.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.