There are alot of tradeoffs here. Some of the challenges with picking your own version numbers - How do you now about compatibility? Who does that analysis? - Confusion for consumers - Ultimately in true OSGi form, the version numbers that matter are the package version numbers. You could use this point to drive either argument but more generally it diminishes the significance of the bundle version number choice. Leaving, IMHO, the best choice to be the simplest (i.e., use the originator's version)
If by wrapping the third party lib you mean nesting JARs, this does indeed work but has a few drawbacks - it doubles the disk footprint of the bundle since the nested JARs will eventually be extracted - you cannot easily/directly use such bundles as development targets since Java compilers and build systems cannot see inside nested JARs. In Eclipse Orbit (http://eclipse.org/orbit) we have choosen to "inject" the metadata directly into the original JARs (where possible) and use the originator's version numbers. Also, the bundle symbolic name is derived from the originator's package naming. The Orbit Wiki has some doc on this. For a more general discussion of bundling random libraries, see the first part of Chapter 20 in the Eclipse RCP book (http://eclipsercp.org). A PDF version is available at http://www.eclipse.org/orbit/documents/RCP_Chapter20.pdf Jeff David Kemper <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/13/2006 11:58 AM Please respond to OSGi Developer Mail List <[email protected]> To <[email protected]> cc Subject Re: [osgi-dev] [equinox-dev] Packaging opensource libraries as osgi bundles If you are going to be packaging open source libraries as OSGi bundles, please be very careful about versioning. The semantics of versioned dependencies (e.g. in Require-Bundle constraints) in OSGi imply specific compatibility requirements. Open source is open source, and some libraries may have versioning that doesn't necessarily adhere to the guidelines. For example an open source library may slip a change into a minor release that breaks backward compatibility, and which may thus unintentionally violate existing dependencies expressed as ranges (e.g. "bundle- version="[1.0.0,2.0.0)"). We have found that it is useful to wrap the existing third-party library archive(s) in our own metadata wrapper so that we may do our own versioning that guarantees such backwards-compatibility constraints. These synthesized versions typically track the underlying library version, but give us the ability to adjust it if we find incompatible changes. This may or may not be applicable to your use cases, but I thought it worth mentioning. /djk _______________________________________________ OSGi Developer Mail List [email protected] http://bundles.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [EMAIL PROTECTED] http://www2.osgi.org/mailman/listinfo/osgi-dev
