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
