We switched to using the maven-bundle-plugin to build our Eclipse
plugins for the Apache UIMA open source project. After an initial
apparent success, we slowly hit several issues that took a lot of
experimental, time-consuming learning to overcome.
The first issue we hit concerned "wrong wiring". What would happen
would be that several testers would try out the plugins, on various
platforms (Windows, Linux, etc), and things would work. An then one
would report a failure. We traced this to Eclipse's use of split
packages. (Background - You can see the list of Eclipse's split
packages by going to the Eclipse "Help" and then searching for the
terms: split packages map)
Our first attempt was to wire a package to a particular bundle. This
worked, but "incrementally" - it would solve one problem, only to have
some testing done later reveal yet another (different) instance of the
split package problem.
Since, in general, it could be the case that "both" sources of a package
would need to be included, we changed the approach to use Require-Bundle
for all the bundles that could supply classes for the split-package.
This, by itself, didn't work - we think it was because the OSGi spec
says that if you have both an "import-package" and a "Require-Bundle",
the Import-Package takes precedence. Here's the quote from the OSGi
spec on this:
A bundle may both import packages (via Import-Package) and require one
or more bundles (via Require-Bundle), but if a package is imported via
Import-Package, it is not also visible via Require-Bundle: Import-Package
takes priority over Require-Bundle, and packages which are exported by a
required bundle and imported via Import-Package must not be treated as
split packages.
So - the next work-around was to add a negative pattern to the
Import-Package for just those packages which were split - to avoid
having them imported. This seemed to work.
The next issue we ran into happened when we tried to use our plugins in
Eclipse 3.2.x. It seems that this level of Eclipse doesn't support the
"uses" clause. The fix here was to eliminate the "uses" clauses, by (a)
using version 1.4.0 of the maven-bundle-plugin, and (b) adding a
<_nouses>true</_nouses> instruction. We also found a further motivation
found for not generating the "uses" clause: this note from the Eclipse
project developers mailing list:
http://dev.eclipse.org/mhonarc/lists/stp-dev/msg01624.html
Other issues we tackled: the maven build of these plugins would work,
but the Eclipse build would often give the following kinds of errors:
Access restriction: The method <some-method-name>() from the type
<some-class-name> is not accessible due to restriction on required
project <some-project-name>
If you opened the project properties and looked at the Java Build Path,
and expanded the plugin-dependencies, you could, indeed, see there were
"Access rules" for the <some-project-name>, but these rules would be
missing the pattern which covered the case for the package where
<some-class-name> lived.
The fix for this (probably really a workaround?) was to add an explicit
"import" for these packages to the POM's maven-bundle-plugin
instruction: <Import-Package> to import these packages. I don't really
understand why this worked, or why the maven-bundle-plugin didn't import
these automagically (the Import-Package list of packages included "*" as
one of the items, which I think means to import all the packages that
were referenced, but not locally available).
We'd be glad to learn of improvements we might make to our build process
:-) .
-Marshall Schor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
