What is the best practices for libraries wrt to importing their own exported packages.
On Thu, Feb 25, 2010 at 17:15, Karl Pauls <karlpa...@gmail.com> wrote: > On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet <gno...@gmail.com> wrote: >> Guys, can we discuss that and come back with a statement we all agree on ? > > Discuss what? > > regards, > > Karl > >> ---------- Forwarded message ---------- >> From: Niall Pemberton <niall.pember...@gmail.com> >> Date: Thu, Feb 25, 2010 at 16:26 >> Subject: Re: [all] OSGI - POOL-160 >> To: Commons Developers List <d...@commons.apache.org> >> >> >> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote: >>> Hi Guillaime, >>> >>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49: >>> >>>> 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." >>> >>> what we are saying is, that none of us is an OSGi expert and before we >>> published the first artifact with such information, we took the advice of >>> the Apache Felix community. If they recommend now something different, we'd >>> like to get some "official" blessing for the changes, simply because we >>> cannot really review it. >> >> +1 >> >> Niall >> >> >>>> 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. >>> >>> What has been released is final. We're not able to change that anymore. All >>> we can do is to change the OSGi information for new releases. >>> >>>> 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))) >>> >>> While I see an error, it does not tell me a lot ;-) >>> >>> - Jörg >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> 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 >> > > > > -- > Karl Pauls > karlpa...@gmail.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com