Hi,
Following the Maven Bundle Plugin's deprecation/removal of the bundleall
goal I was pointed to the option of creating an uber-bundle for my
project's dependencies (see
https://issues.apache.org/jira/browse/FELIX-4145). This took
considerable effort compared to using the bundleall goal, and I'd like
to raise some thoughts about the process - I don't know if these are
bugs, features, or my own misunderstanding, but I hope they can be used
to improve the migration experience for anyone else who currently uses
the bundleall/wrap goals and will shortly be required to migrate away
from them.
What I did in a nutshell: I created a project for the uber-bundle, with
the dependencies being the packages it will need to include (all with
explicit versions inherited from the parent pom's DependencyManagement).
The new project's version is currently 0.1-SNAPSHOT. I'm using the
Embed-Dependency configuration along with Embed-Transitive set to true
to hand-pick the dependencies and transitive dependencies that I need to
add to the bundle. The project contains nothing other than its pom (no
real sources or resources).
1. In the generated bundle, the generated Export-Package header in the
manifest specifies the version of the exported packages as version
0.1.SNAPSHOT. When using the bundleall goal it would correctly take the
artifact version and use that in the exports version, but now this
information seems lost, and I have to manually go over all the exports
and specify their respective versions in the _exportcontents
configuration. Is this a bug? Why not use maven's existing version
information for these dependencies and save all the tedious work,
duplicate/error-prone versioning info? (btw one of the dependencies
already had the OSGi headers - in this case the dependency's export
version seems to have been copied over correctly to the uber-bundle's
exports).
2. The uber-bundle's Export-Package header seems to include non-package
resources such as the dependency jar names themselves, a License.txt
file it probably picked up from one of the bundles, etc. The maven build
actually gives a warning, e.g. "Invalid package name: 'guava-14.0.jar'".
I ended up adding !*.jar,!*.xml,!*.txt to the _exportcontents
configuration to prevent the warnings and incorrect exports header. Is
this a bug or a feature?
3. Similarly, when I try to set Embed-StripGroup to false, the jars are
placed ain group-named directories, but then the directory names
themselves are added to the exports header (without the jar name). One
of the group names happened to contain a hyphen, which resulted in an
"Invalid package name" header as well. I added an additional !*-* to the
exportcontents configuration to prevent this as well. Again, a lot of
unnecessary and tedious troubleshooting.
4. One of the embedded dependencies already had OSGi headers, and while
the export info (e.g. version, see #1) seemed to be copied over
correctly, the imports, and specifically the "resolution:=optional"
parameter, was not - this meanse I need to manually go over all imports
of the bundles and explicit copy over this parameter into the
uber-bundle's Import-Package configuration for all optional imports of
all dependency bundles. Very tedious and unnecessary. A bug?
5. By default the embedded dependencies are not exported by the
uber-budnle, until Exported-Package is specified. It is natural in many
cases (particularly when migrating from bundleall) to want to specify *
and export everything as before. However, as I eventually found in the
documentation, the default behavior is to then embed everything twice in
the bundle - one in the jars, and once inlined, and Export-Package needs
to be replaced with _exportcontents in order to get the desired result.
I don't know what the use case is where one would want to include
everything twice, but perhaps this should at least not be made the
default behavior?
In summary, what I had to do to get the desired uber-bundle is create
the new project, add its dependencies, set Embed-Transitive to true,
specify the actual jars to embed in Embed-Dependency (up to here this
makes sense), generate the uber-jar, figure out why I'm getting warning
about jar names appearing as invalid package names, add hacky globs to
Export-Package to prevent them, (I took the detour of trying
Embed-StripGroup as well and doubling the invalid package name effort),
generate the uber-jar again, manually go over the exports in its
manifest looking for all those with the wrong version, find the correct
version for each and specify the package+version manually in
Export-Package, go over all imports in all OSGi-ready embedded
dependencies and specify the package+resolution:=optional parameter
manually in Import-Package for all those with an optional resolution,
move all of Export-Package into _exportcontents once I figured it needs
to be done, and finally arrive in a working bundle (I hope :-) ). That's
a lot of work that seems unnecessary, error-prone and difficult to
maintain when something changes in the future, and took even more time
to try googling, asking, reading documentation and experimenting with
until I figured out what needs to be done.
All that being said, I hope this feedback can be used to improve the
experience for the next guy or gal that'll need to migrate away from the
bundleall goal and save them a lot of time and effort. At the very
least, there should be configurable options to do these things
automatically, or even a "bundleall" configuration option that does what
one would expect (embed jars, retain embedded osgi headers and assign
proper version numbers, remove duplication and unnecessary included
resources, etc.). Anyone wishing to further tweak or override these can
of course already do that.
I'll only add another little suggestion:
6. It would be nice if the helpful original response I got in
FELIX-4145, and possibly some more examples specific to bundleall
migration and overcoming some of the above issues, would be documented
and linked from the wrap/bundleall documentation pages, right near the
deprecation notice - that's the first place many people would look when
trying to figure out how they can move past the deprecation and figure
out what the new recommended solution is.
I realize some of this hard work may have been due to my own
misunderstandings, but that can happen to the next guy as well, so any
way to save him the trouble would be a blessing.
Thanks, and I hope this has been useful to someone :-)
Amichai
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
