felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Rothman" <amich...@amichais.net>
Subject Bundleall replacement
Date Mon, 24 Jun 2013 09:35:24 GMT

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 

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 :-)


To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message