On Fri, Feb 26, 2010 at 2:45 PM, Guillaume Nodet <gno...@gmail.com> wrote: > FWIW, I would ensure that all imported packages in OSGi have a range > on the imported package (if they don't come from the JVM). > For example on > http://people.apache.org/~niallp/osgi-feb-2010/beanutils-MANIFEST.MF, > the Import-Package should look like: > > Import-Package: > org.apache.commons.collections.comparators;version="[1.0,2.0)",org.apache. > commons.collections.keyvalue;version="[1.0,2.0)",org.apache.commons.collections.list;version="[1.0,2.0)",org. > apache.commons.collections.set;version="[1.0,2.0)",org.apache.commons.logging;version="[1.0,2.0)" > > The ranges I've written above are purely wild guesses and they should > be thought about a bit more. Not giving a range is bound > to problems if there is an older version deployed (which could not > contain the needed features), or if commons ever release a new major > version of one component and breaks backward compatibility (which is > fine for a major version). > > I can try to go through all of them if you're interesed but a first > step would be to add the following to the parent pom in the > maven-bundle-plugin configuraiton: > <instructions> > ... > <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy> > </instructions> > > The effect will be to generate a range up to (but not including) the > next major version. The problem is that it will only work if a > version can be infered by the maven plugin (usually by looking at the > manifest of the dependencies). > > I can help a bit on that if you're willing to go that way.
I think the problem is that although we were happy to put OSGi meta data in our manifests I don't think the developers here are using OSGi. We have the configuration (mostly) at the commons-parent pom level - but I think if it requires most components having to configure this themselves on a per-component basis - then I don't think these will be maintained properly or people will spot when they're not correct. Niall > On Fri, Feb 26, 2010 at 02:26, Niall Pemberton > <niall.pember...@gmail.com> wrote: >> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <gno...@gmail.com> wrote: >>> 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). >> >> Its annoying since it came up three times on d...@felix and other felix >> developers said the opposite >> >> http://markmail.org/message/5xwuqjaycupfxwh5 >> >> I guess we go with the current advice and hope its right this time. I >> have updated the commons-parent pom.xml to not re-import the >> component's packages: >> >> http://svn.apache.org/viewvc?view=revision&revision=916523 >> >> I have also built all the components using that version of the parent >> pom and their generated manifests are here fore review: >> >> http://people.apache.org/~niallp/osgi-feb-2010/ >> >> Niall >> >> >>> ---------- 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 >>> >>> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
