John E. Conlon wrote: > Ceki Gülcü wrote: > >> Comments inline. >> >> At 01:32 AM 1/31/2007, John E. Conlon wrote: >> >>> Peter Kriens' Bnd tool for OSGi bundle creation is a very handy tool for >>> creating and verifying bundles. >>> See: http://www.aqute.biz/Code/Bnd >>> >>> I used it to verify our maven created jars and it reported a couple of >>> errors with our OSGi metadata. Here is an example of the output from >>> the tool: >>> >> [snip] >> >> >>> 4 : Invalid value for Bundle-Version, 1.3-SNAPSHOT does not match >>> [0-9]+(\.[0-9]+(\.[0-9]+(\.[0-9A-Za-z_-]+)?)?)? >>> >> Reading the above message, I would say that "1.3-SNAPSHOT" is not a >> legal version number but "1.3.0-SNAPSHOT" is. So we can perhaps retain >> > Actually "1.3.0-SNAPSHOT" is not legal but "1.3.0.-SNAPSHOT" is. > >> <Bundle-Version>${project.version}</Bundle-Version> >> > I like keeping it all in one place as you have above. > >> instead of >> >> <Bundle-Version>1.3.0.SNAPSHOT</Bundle-Version> >> > Right, rather not have the above. > >> in pom.xml, subject to the condition that ${project.version} equals >> "1.3.0-SNAPSHOT" or 1.3.0 or 1.3 but not 1.3-SNAPSHOT. >> > Again we would need a third period before the dash or letters. as in > "1.3.0.-SNAPSHOT" > >>> Would it cause anyone any pain if we removed the Bundle-Classpath from >>> our manifests? >>> >> The current manifest entries mimic the entires found in Spring-OSGi >> (see [1]). I don't mind if they are removed although I wonder why they >> are present in spring-osgi. >> > Some developers are using the Eclipse to build the manifests and Maven > for project layout. When this is done they are have to use the > Bundle-Classpath with as a hack to get the project recognized by > Eclipse. > > Generating the metadata by hand or with assistance from Eclipse within a > Maven project often runs into problems. > The preferred practice is to use the bnd tool which is also available as > a maven plugin. The plugin version will automatically generate much of > the manifest from the pom. For example: > <Bundle-Version> is assumed to be "${pom.version}" with '-' > character separator of the qualifier replaced with a '.' character. > > I have not used the plugin with 'Split Packages' that need > Require-Bundle for package aggregation (like we are doing in slf4j), but > tomorrow I will experiment with it to see how it handles these. > Peter has no plans to support Require-Bundle in the plugin, so I guess we must manually edit the plugin or create a new one ourselves. Just so you know - although supported by the spec Require-Bundle is not considered 'best practice' for specifying dependencies between packages in bundles.
For some of the issues and potential problems see 1. The OSGi specificati blog entry of archive - http://www.osgi.org/blog/2006_01_01_archive.html 2. Or this background - http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html 3. The r4 core spec Section 3.13 'Requiring Bundles'. Goto http://osgi.org/osgi_technology/download_specs.asp?section=2 to request the spec. cheers, John > BTW - Richard Hall only commited the Require-Bundle functionality to > Felix today! > > _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
