The weird thing is that it seems Peter Kriens BND tool should be able to do that automatically, see http://www.aqute.biz/Bnd/Versioning, so instead of starting fixing all the poms, we may want to investigate why it does not do its job properly. Maybe the maven bundle plugin uses an older version of BND, or BND needs to be configured somehow ?
On Tue, Feb 8, 2011 at 16:32, zoe slattery <[email protected]> wrote: > Yes - I agree that that needs fixing. > >> 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 >>>>> >>>> >>> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
