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]
