aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Breaking the ties between aries components/importing version ranges
Date Mon, 07 Feb 2011 14:38:14 GMT
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 <> 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,
> 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

Guillaume Nodet
Open Source SOA

View raw message