The code is at https://github.com/bnd/bnd/blob/master/biz.aQute.bndlib/src/aQute/lib/osgi/Analyzer.java#L1239 I think we need to replace the line boolean impl = isTrue(currentAttributes.get(PROVIDE_DIRECTIVE)); with something smarter.
On Tue, Feb 8, 2011 at 21:40, Guillaume Nodet <[email protected]> wrote: > I think BND already scans the classes using ASM, so maybe we could > patch it to actually detect such patterns. > > On Tue, Feb 8, 2011 at 20:40, zoe slattery <[email protected]> wrote: >> From the bnd docs: >> >> "How does bnd know if a bundle is a provider or a consumer of a specific >> package? Well, the default is the consumer policy but this can be overridden >> with the |provide:=true| directive that works on the |Import-Package| >> clauses as well as on the |Export-Package| clauses. : >> >> So, I tried adding a provide:=true against an import of o.a.a.proxy in the >> proxy-impl/pom.xml. This does the job. >> Pity - would be nice if bnd looked for the 'implements' in the source and >> figured it out. Perhaps this is very hard to do? >> >> Zoe >>> >>> We probably need to remove the version policy statement in the >>> default-parent pom. >>> >>> On 8 February 2011 16:53, zoe slattery<[email protected]> wrote: >>>> >>>> Sure - I will try that. It maybe that's all we need. >>>>> >>>>> I think so too. Zoe, could you try upgrading to the 2.3.4 maven >>>>> bundle plugin which has just been released? >>>>> >>>>> On Tue, Feb 8, 2011 at 17:46, Felix Meschberger<[email protected]> >>>>> wrote: >>>>>> >>>>>> Shouldn't BND recognize this situation ? That's how I understood the >>>>>> docs, anyway. >>>>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>> Am Dienstag, den 08.02.2011, 16:31 +0000 schrieb zoe slattery: >>>>>>> >>>>>>> Yes - BND will do it, I think we just need to tell it that we are an >>>>>>> 'implementer' , looks like its default assumption is 'consumer'. >>>>>>> Z >>>>>>>> >>>>>>>> Sorry I misread the point. This is because we haven't told bnd to >>>>>>>> generate a version range for implementors, as I recall there is >>>>>>>> something specific you need to set. >>>>>>>> >>>>>>>> On 8 February 2011 16:12, Alasdair Nottingham<[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> That is probably because the proxy pom.xml which defines the version >>>>>>>>> of proxy-api to depend on has 0.4-SNAPSHOT in it. If it was >>>>>>>>> 0.3-SNAPSHOT you would get the right version range. >>>>>>>>> >>>>>>>>> Alasdair >>>>>>>>> >>>>>>>>> On 8 February 2011 15:53, zoe slattery<[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hmm - well - I reverted my change and actually the range for the >>>>>>>>>> import was >>>>>>>>>> wrong before. My changes made no difference, but I do agree that it >>>>>>>>>> needs to >>>>>>>>>> be fixed and will work on it. >>>>>>>>>> Zoe >>>>>>>>>>> >>>>>>>>>>> Well, I think the result is plain wrong. >>>>>>>>>>> For example proxy/proxy-impl imports the org.apache.aries.proxy >>>>>>>>>>> package with a [0.4,1) range. >>>>>>>>>>> However, given it implements the spec, the semantic versioning >>>>>>>>>>> guidelines indicates that the range should be [0.4,0.5). >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 8, 2011 at 16:03, zoe slattery<[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> OK - I have checked in a change under >>>>>>>>>>>> https://issues.apache.org/jira/browse/ARIES-571 which reverts the >>>>>>>>>>>> dependency >>>>>>>>>>>> between Aries modules. >>>>>>>>>>>> I have checked that import ranges are calculated correctly by the >>>>>>>>>>>> maven >>>>>>>>>>>> bundle plugin. The range is now based on the version of the >>>>>>>>>>>> dependency. >>>>>>>>>>>> >>>>>>>>>>>> So, for example, a module that depends (as a consumer) on >>>>>>>>>>>> util-0.4-SNAPSHOT >>>>>>>>>>>> will import util packages in the range [0.4, 1.0). A module that >>>>>>>>>>>> depends >>>>>>>>>>>> on >>>>>>>>>>>> util-0.3 will import util packages in the range [0.3, 1.0). >>>>>>>>>>>> >>>>>>>>>>>> Everything builds and all the tests run. >>>>>>>>>>>> >>>>>>>>>>>> Zoe >>>>>>>>>>>>> >>>>>>>>>>>>> Actually, after thinking about it, I don't think there's much >>>>>>>>>>>>> problem. >>>>>>>>>>>>> So please go ahead. >>>>>>>>>>>>> We also need to make sure about the versions range we use for >>>>>>>>>>>>> imports, >>>>>>>>>>>>> i.e. up to the next major for a used package, and up to the >>>>>>>>>>>>> minor >>>>>>>>>>>>> version if the package is implemented somehow. BND is supposed >>>>>>>>>>>>> to >>>>>>>>>>>>> do >>>>>>>>>>>>> that automatically now, but we'd have to double check. >>>>>>>>>>>>> Also, if we keep old versions for dependencies, we'd still need >>>>>>>>>>>>> to >>>>>>>>>>>>> test with recent ones I think, so not sure how to deal with >>>>>>>>>>>>> that. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Feb 7, 2011 at 15:38, Guillaume Nodet<[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the original code did not use version ranges and early >>>>>>>>>>>>>> version >>>>>>>>>>>>>> of maven bundle plugin did not allow for policies on creating >>>>>>>>>>>>>> ranges. >>>>>>>>>>>>>> That can be change if needed obviously. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Before doing any breaking changes in the way we release / >>>>>>>>>>>>>> version >>>>>>>>>>>>>> packages or bundles, can we continue the discussion and have a >>>>>>>>>>>>>> clear >>>>>>>>>>>>>> picture where we are going to ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> There's no need to do the work multiple times, so if you're >>>>>>>>>>>>>> gonna >>>>>>>>>>>>>> break that link, what do you plan to put instead ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Feb 7, 2011 at 15:31, zoe >>>>>>>>>>>>>> slattery<[email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is something that I would like to change in the way we >>>>>>>>>>>>>>> build >>>>>>>>>>>>>>> Aries. >>>>>>>>>>>>>>> I'm asking because I don't really understand why it is there >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> first >>>>>>>>>>>>>>> place. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Today, if I am building blueprint at version 0.4-SNAPSHOT, the >>>>>>>>>>>>>>> blueprint >>>>>>>>>>>>>>> bundle manifests which are generated all import versions of >>>>>>>>>>>>>>> other >>>>>>>>>>>>>>> aries >>>>>>>>>>>>>>> components in the range [0.4, 1.0). This is true even if I >>>>>>>>>>>>>>> modify a >>>>>>>>>>>>>>> blueprint pom to explicitly depend on, say >>>>>>>>>>>>>>> org.apache.aries.proxy at >>>>>>>>>>>>>>> version >>>>>>>>>>>>>>> 0.3. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The import range is calculated (by some logic in the default >>>>>>>>>>>>>>> parent >>>>>>>>>>>>>>> pom) >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> a way that creates a tie between all of the aries components, >>>>>>>>>>>>>>> it >>>>>>>>>>>>>>> also >>>>>>>>>>>>>>> overrides the default behaviour of the maven bundle plugin >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>> calculates >>>>>>>>>>>>>>> import ranges based on the version of the dependency. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In some cases I notice that people have worked around this >>>>>>>>>>>>>>> behaviour >>>>>>>>>>>>>>> by >>>>>>>>>>>>>>> hard >>>>>>>>>>>>>>> coding import ranges in the pom, see for example, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-core/pom.xml >>>>>>>>>>>>>>> and the way that it imports org.apache.aries.quiesce.manager. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would like to remove the logic from the default parent pom >>>>>>>>>>>>>>> that does >>>>>>>>>>>>>>> this. >>>>>>>>>>>>>>> However - I don't understand why it is there in the first >>>>>>>>>>>>>>> place, >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> anyone >>>>>>>>>>>>>>> explain? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Zoe >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>> Open Source SOA >>>>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Alasdair Nottingham >>>>>>>>> [email protected] >>>>>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > > > > -- > 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
