Sure, these motivations seem to make sense in your scenario but I suspect that some of your requirements/premises are not typically applicable.
Of course, people need to consult their own lawyers but the open source libs we have seen do not present a problem for inserting files. Note that we also sign these libs. This ends up inserting files and modifying the manifest and these modifications are effectively mandated by the Java signing approach (i.e., you cannot get around this if you want/need to sign). Establishing compatibility is from the outside (i.e., not being a part of the producing team) feels like a huge burden. Its not even clear that you could do it with confidence in the general case. That is, establishing compatibility/suitability for YOUR use of the library is likely doable in a reasonable way. When you make a bundle out of this stuff and version it with semantics however, you are making a more general statement than that. Others are going to show up and interpret those version numbers and think that hey, 1.1 is compatible with 1.0 so everything should be ok. For this to work, either the producers of the code had a strong compatibilty ethic or you had a wildly detailed test/inspection process. In the former case, (compatibility ethic) you would not need to establish different version numbering schem since the existing ones already capture the needed semantics. The latter case hurts my head. Anyway, clearly you need to do what you need to do and I'm certainly not trying to convince you otherwise. I am however bummed by this as a general guideline for bundling third party libraries. Jeff David Kemper <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/29/2006 04:59 PM Please respond to OSGi Developer Mail List <[email protected]> To <[email protected]> cc Subject [osgi-dev] Re: [equinox-dev] Packaging opensource libraries as osgi bundles (Jeff McAffer) I'm working my way through post-release and post-vacation email, so this thread has been cold for a while. But for what it's worth: Thanks for the followup. My issues with packaging open source libraries follow from the following: 1) From a legal perspective we do not want to touch the open source library at all, even to "simply" add OSGi framework headers. Thus we package the library in a directory-based plugin (not a JAR plugin with a nested JAR) with the metadata in that directory structure. Now, I'm not a lawyer, and I can't really comment much more on the legal issues, but in general we can wrap but we can't change the dependency. 2) We predominantly use Require-Bundle for our dependencies. For better or worse, we want this level of control over what component/ version is supplying the dependency. Yes this can be done with filters on the import- and export- packages, but the require bundles seemed to fit our needs. We typically write the dependency with a range qualifier of [x.0.0,x+1.0.0) assuming that changes in the major version mark possible breaks in backwards compatibility. 3) Since we have to live with the consequences, we determine compatibility against our uses of the libraries. We're on the hook if something goes wrong ;-) Now, as these libraries become available with accurate OSGi metadata, we can determine how to best use them (or not) for our use cases. /djk > Message: 1 > Date: Fri, 17 Nov 2006 21:26:09 -0500 > From: Jeff McAffer <[EMAIL PROTECTED]> > Subject: Re: [osgi-dev] [equinox-dev] Packaging opensource libraries > as osgi bundles > To: OSGi Developer Mail List <[email protected]> > Message-ID: > <OF2DA89347.EBB4E741-ON8525722A.000C44DF-8525722A. > [EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > 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://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
