Forwarding the current discussion on felix dev list. Hopefully this should settle thing a bit. Both Karl and Richard says the FAQ looks clear enough (that's the one I pointed you to earlier too).
---------- Forwarded message ---------- From: Guillaume Nodet <gno...@gmail.com> Date: Thu, Feb 25, 2010 at 18:01 Subject: Re: [all] OSGI - POOL-160 To: d...@felix.apache.org I think I'll foward this discussion back to their dev list and things should be ok I suppose. On Thu, Feb 25, 2010 at 17:44, Richard S. Hall <he...@ungoverned.org> wrote: > On 2/26/10 12:40 AM, Guillaume Nodet wrote: >> >> It does not seem to be sufficient to the commons guys as the want an >> "official" and expert blessing from the felix community because it >> kinda contradicts the earlier statement they had from Peter which said >> that importing your exported packages is a best practice in osgi. >> > > Well, they should have talked to us. ;-) > > Seriously, what more can we say? The FAQ has existed for a fairly long time > and our story hasn't changed. Are you suggesting that we need to change the > FAQ in some way? Or are you saying that you want some official OSGi Alliance > statement on this? > > As it stands, I think the FAQ tries to explain the issues for deciding what > you should do fairly well, but we're willing to improve it if it is not > clear. > > -> richard > >> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<karlpa...@gmail.com> wrote: >> >>> >>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gno...@gmail.com> >>> wrote: >>> >>>> >>>> What is the best practices for libraries wrt to importing their own >>>> exported packages. >>>> >>> >>> Well, I still don't know what you want to discuss. We have this in the >>> FAQ: >>> >>> 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. Another case might be if you have tightly coupled bundles >>> sharing implementation packages. However, if your bundle will be >>> started and especially if the exported packages define service >>> interfaces or are referenced from service interfaces, then you will >>> generally want to export and import them. >>> >>> which seems to be good and is what seems to be not followed in the >>> below use case - which causes a problem. If commons pool wouldn't >>> import what it exports then everything would have been fine no? >>> >>> Obviously, there is now single answer to this problem but the FAQ >>> seems correct to me. I guess I'm still missing the point. >>> >>> regards, >>> >>> Karl >>> >>> >>>> >>>> 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<dev@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 >>>> >>>> >>> >>> >>> -- >>> Karl Pauls >>> karlpa...@gmail.com >>> >>> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com -- 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
