I just had a lively chat with Peter who kinda agreed that substitutability issue is mostly important for APIs.
Please have a look at the Felix FAQ entry: http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F I haven't written it, so I can't be blame for that one. The last paragraph says: "The main time you want to export only, is if your bundle is purely a library bundle, then its packages will only be used if they are needed." In all cases, the current imports *are* wrong and need to be fixed, because the way they are written will fail if there is any incompatible change ever introduced (whatever the version). And I don't think we should guarantee that, especially across major versions. Anyway, the problem is the following. You install commons-pool 1.5 in the osgi framework. Then you install commons-pool 1.4 later. What you end up with is: ka...@root> osgi:list -l | grep commons-pool [ 100] [Active ] [ ] [ ] [ 60] mvn:commons-pool/commons-pool/1.5.4 [ 124] [Active ] [ ] [ ] [ 60] mvn:commons-pool/commons-pool/1.4 ka...@root> packages:exports 100 Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4 Commons Pool (100): org.apache.commons.pool; version=1.5.4 ka...@root> packages:exports 124 Apache Commons Pool Bundle (124): No active exported packages. ka...@root> packages:imports 124 Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4 Commons Pool (100): org.apache.commons.pool; version=1.5.4 ka...@root> osgi:start 170 Error executing command: Unresolved constraint in bundle org.apache.activemq.activemq-pool [129]: package; (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!(version>=1.5.0))) On Thu, Feb 25, 2010 at 14:26, Jörg Schaible <joerg.schai...@gmx.de> wrote: > Hi Guillaume, > > Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 14:13: > >> I'm not a committer on commons, but I've diagnosed the issue we had in >> ServiceMix with the commons-pool bundles. >> I can confirm that the patch is the right way to go. If a bundle >> acting as a library imports its own exported packages, you're bound to >> a lot of problems. > > Well, this has come up before and was an explicit recommendation by the > experts: > > Peter Kriens: "Bnd automatically imports all exports to allow > substitutability. If you do not do this, you create all kinds of standalone > class spaces and things will not work together. It is generally bad practice > to only export a package." > > http://commons.markmail.org/message/lgmj7srrxhld42tp > >> This problem applies to all releases of commons-pool and maybe to >> other commons-xxx components. >> I need to try if, but a better way might be to change the >> commons-parent pom with something like: >> >> <commons.osgi.export>org.apache.commons.*;version=${pom.version};- > noimport</commons.osgi.export> >> >> This should work the same (i.e. not import our own exports), but be >> applicable to all modules. > > I'd rather not chage this unless proven by the experts again... > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
