felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Rothman" <amich...@amichais.net>
Subject Re: Bundleall replacement
Date Thu, 01 Aug 2013 09:21:14 GMT

Should I open a JIRA ticket for this? Or multiple tickets? Are these 
confirmed bugs or is something by design?

On 06/24/2013 12:35 PM, A. Rothman wrote:
> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message