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
