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] >>>>>> >>>>> >>> >>> >> >> > > -- Alasdair Nottingham [email protected]
