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]
