On Thu, Feb 25, 2010 at 4:44 PM, Richard S. Hall <[email protected]> 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. ;-)
It came up in three separate threads, here and there was consistently the same message :( http://felix.markmail.org/message/qp33zosdp43e2vnv http://felix.markmail.org/message/tczwuc4qfdo3kpey http://felix.markmail.org/message/4y6s7eqdsg5nirvg http://felix.markmail.org/message/lg7w4qtetfvhncte > Seriously, what more can we say? We asked for confirmation from you guys because it had come up several times and was the opposite of the advice we had been given here. Niall > 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<[email protected]> wrote: >> >>> >>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<[email protected]> >>> 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<[email protected]> wrote: >>>> >>>>> >>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<[email protected]> >>>>> 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<[email protected]> >>>>>> Date: Thu, Feb 25, 2010 at 16:26 >>>>>> Subject: Re: [all] OSGI - POOL-160 >>>>>> To: Commons Developers List<[email protected]> >>>>>> >>>>>> >>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<[email protected]> >>>>>> 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: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> Open Source SOA >>>>>> http://fusesource.com >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Karl Pauls >>>>> [email protected] >>>>> >>>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >>>> >>> >>> >>> -- >>> Karl Pauls >>> [email protected] >>> >>> >> >> >> >
