You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by zoe slattery <zo...@gmail.com> on 2011/02/07 15:31:35 UTC
Breaking the ties between aries components/importing version ranges
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
Re: Breaking the ties between aries components/importing version
ranges
Posted by zoe slattery <zo...@gmail.com>.
Thanks Guillaume. I won't actually check anything in until I'm convinced
that the bnd plugin does the right thing for us. I'll get back to the
list if I have questions.
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<gn...@gmail.com> 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<zo...@gmail.com> 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
>>
>
>
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <zo...@gmail.com> 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<zo...@gmail.com> 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<gn...@gmail.com>
>>>> 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<zo...@gmail.com>
>>>>> 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
Re: Breaking the ties between aries components/importing version
ranges
Posted by zoe slattery <zo...@gmail.com>.
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<zo...@gmail.com> 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<gn...@gmail.com> 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<zo...@gmail.com>
>>>> 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
>>>>
>>>
>>
>
>
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
I've actually just done that in bnd, but I think that's what really
the expected behavior.
Quoting Peter Kriens:
"Provide and consume is orthogonal to implementing an interface and
delegating. For example, the Configuration Admin service has the
ConfigurationAdmin interface that is implemented by the Provider of an
API but the ConfigurationListener interface is implemented by the
Consumer of the API."
So this provide directive actually has to be set manually I think and
I think such a patch would not be a good idea.
On Tue, Feb 8, 2011 at 21:55, Guillaume Nodet <gn...@gmail.com> wrote:
> The code is at https://github.com/bnd/bnd/blob/master/biz.aQute.bndlib/src/aQute/lib/osgi/Analyzer.java#L1239
> I think we need to replace the line
> boolean impl = isTrue(currentAttributes.get(PROVIDE_DIRECTIVE));
> with something smarter.
>
> On Tue, Feb 8, 2011 at 21:40, Guillaume Nodet <gn...@gmail.com> wrote:
>> I think BND already scans the classes using ASM, so maybe we could
>> patch it to actually detect such patterns.
>>
>> On Tue, Feb 8, 2011 at 20:40, zoe slattery <zo...@gmail.com> wrote:
>>> From the bnd docs:
>>>
>>> "How does bnd know if a bundle is a provider or a consumer of a specific
>>> package? Well, the default is the consumer policy but this can be overridden
>>> with the |provide:=true| directive that works on the |Import-Package|
>>> clauses as well as on the |Export-Package| clauses. :
>>>
>>> So, I tried adding a provide:=true against an import of o.a.a.proxy in the
>>> proxy-impl/pom.xml. This does the job.
>>> Pity - would be nice if bnd looked for the 'implements' in the source and
>>> figured it out. Perhaps this is very hard to do?
>>>
>>> Zoe
>>>>
>>>> We probably need to remove the version policy statement in the
>>>> default-parent pom.
>>>>
>>>> On 8 February 2011 16:53, zoe slattery<zo...@gmail.com> 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<fm...@gmail.com>
>>>>>> 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<no...@apache.org>
>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>>>> 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<gn...@gmail.com>
>>>>>>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>>>>>>> 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
>>>>>>>>>> not@apache.org
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> 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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
The code is at https://github.com/bnd/bnd/blob/master/biz.aQute.bndlib/src/aQute/lib/osgi/Analyzer.java#L1239
I think we need to replace the line
boolean impl = isTrue(currentAttributes.get(PROVIDE_DIRECTIVE));
with something smarter.
On Tue, Feb 8, 2011 at 21:40, Guillaume Nodet <gn...@gmail.com> wrote:
> I think BND already scans the classes using ASM, so maybe we could
> patch it to actually detect such patterns.
>
> On Tue, Feb 8, 2011 at 20:40, zoe slattery <zo...@gmail.com> wrote:
>> From the bnd docs:
>>
>> "How does bnd know if a bundle is a provider or a consumer of a specific
>> package? Well, the default is the consumer policy but this can be overridden
>> with the |provide:=true| directive that works on the |Import-Package|
>> clauses as well as on the |Export-Package| clauses. :
>>
>> So, I tried adding a provide:=true against an import of o.a.a.proxy in the
>> proxy-impl/pom.xml. This does the job.
>> Pity - would be nice if bnd looked for the 'implements' in the source and
>> figured it out. Perhaps this is very hard to do?
>>
>> Zoe
>>>
>>> We probably need to remove the version policy statement in the
>>> default-parent pom.
>>>
>>> On 8 February 2011 16:53, zoe slattery<zo...@gmail.com> 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<fm...@gmail.com>
>>>>> 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<no...@apache.org>
>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>>> 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<gn...@gmail.com>
>>>>>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>>>>>> 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
>>>>>>>>> not@apache.org
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> --
> 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
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
I think BND already scans the classes using ASM, so maybe we could
patch it to actually detect such patterns.
On Tue, Feb 8, 2011 at 20:40, zoe slattery <zo...@gmail.com> wrote:
> From the bnd docs:
>
> "How does bnd know if a bundle is a provider or a consumer of a specific
> package? Well, the default is the consumer policy but this can be overridden
> with the |provide:=true| directive that works on the |Import-Package|
> clauses as well as on the |Export-Package| clauses. :
>
> So, I tried adding a provide:=true against an import of o.a.a.proxy in the
> proxy-impl/pom.xml. This does the job.
> Pity - would be nice if bnd looked for the 'implements' in the source and
> figured it out. Perhaps this is very hard to do?
>
> Zoe
>>
>> We probably need to remove the version policy statement in the
>> default-parent pom.
>>
>> On 8 February 2011 16:53, zoe slattery<zo...@gmail.com> 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<fm...@gmail.com>
>>>> 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<no...@apache.org>
>>>>>>> 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<zo...@gmail.com>
>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>> 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<gn...@gmail.com>
>>>>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>>>>> 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
>>>>>>>> not@apache.org
>>>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Breaking the ties between aries components/importing version
ranges
Posted by zoe slattery <zo...@gmail.com>.
From the bnd docs:
"How does bnd know if a bundle is a provider or a consumer of a specific
package? Well, the default is the consumer policy but this can be
overridden with the |provide:=true| directive that works on the
|Import-Package| clauses as well as on the |Export-Package| clauses. :
So, I tried adding a provide:=true against an import of o.a.a.proxy in
the proxy-impl/pom.xml. This does the job.
Pity - would be nice if bnd looked for the 'implements' in the source
and figured it out. Perhaps this is very hard to do?
Zoe
> We probably need to remove the version policy statement in the
> default-parent pom.
>
> On 8 February 2011 16:53, zoe slattery<zo...@gmail.com> 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<fm...@gmail.com>
>>> 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<no...@apache.org> 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<zo...@gmail.com>
>>>>>>> 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<zo...@gmail.com>
>>>>>>>>> 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<gn...@gmail.com>
>>>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>>>> 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
>>>>>>> not@apache.org
>>>>>>>
>>>>
>>>
>>
>
>
Re: Breaking the ties between aries components/importing version ranges
Posted by Alasdair Nottingham <no...@apache.org>.
We probably need to remove the version policy statement in the
default-parent pom.
On 8 February 2011 16:53, zoe slattery <zo...@gmail.com> 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<fm...@gmail.com>
>> 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<no...@apache.org> 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<zo...@gmail.com>
>>>>>> 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<zo...@gmail.com>
>>>>>>>> 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<gn...@gmail.com>
>>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>>> 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
>>>>>> not@apache.org
>>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: Breaking the ties between aries components/importing version
ranges
Posted by zoe slattery <zo...@gmail.com>.
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<fm...@gmail.com> 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<no...@apache.org> 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<zo...@gmail.com> 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<zo...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>> 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<zo...@gmail.com>
>>>>>>>>>> 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
>>>>> not@apache.org
>>>>>
>>>>
>>
>>
>
>
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <fm...@gmail.com> 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<no...@apache.org> 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<zo...@gmail.com> 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<zo...@gmail.com> 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<gn...@gmail.com>
>> >>>>>> 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<zo...@gmail.com>
>> >>>>>>> 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
>> >> not@apache.org
>> >>
>> >
>> >
>>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Breaking the ties between aries components/importing version
ranges
Posted by Felix Meschberger <fm...@gmail.com>.
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<no...@apache.org> 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<zo...@gmail.com> 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<zo...@gmail.com> 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<gn...@gmail.com>
> >>>>>> 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<zo...@gmail.com>
> >>>>>>> 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
> >> not@apache.org
> >>
> >
> >
>
Re: Breaking the ties between aries components/importing version
ranges
Posted by zoe slattery <zo...@gmail.com>.
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<no...@apache.org> 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<zo...@gmail.com> 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<zo...@gmail.com> 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<gn...@gmail.com>
>>>>>> 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<zo...@gmail.com>
>>>>>>> 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
>> not@apache.org
>>
>
>
Re: Breaking the ties between aries components/importing version ranges
Posted by Alasdair Nottingham <no...@apache.org>.
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 <no...@apache.org> 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 <zo...@gmail.com> 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<zo...@gmail.com> 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<gn...@gmail.com>
>>>>> 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<zo...@gmail.com>
>>>>>> 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
> not@apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: Breaking the ties between aries components/importing version ranges
Posted by Alasdair Nottingham <no...@apache.org>.
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 <zo...@gmail.com> 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<zo...@gmail.com> 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<gn...@gmail.com>
>>>> 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<zo...@gmail.com>
>>>>> 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
not@apache.org
Re: Breaking the ties between aries components/importing version
ranges
Posted by zoe slattery <zo...@gmail.com>.
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<zo...@gmail.com> 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<gn...@gmail.com> 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<zo...@gmail.com>
>>>> 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
>>>>
>>>
>>
>
>
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <zo...@gmail.com> 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<gn...@gmail.com> 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<zo...@gmail.com>
>>> 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
Re: Breaking the ties between aries components/importing version
ranges
Posted by zoe slattery <zo...@gmail.com>.
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<gn...@gmail.com> 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<zo...@gmail.com> 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
>>
>
>
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@gmail.com> 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 <zo...@gmail.com> 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
Re: Breaking the ties between aries components/importing version ranges
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <zo...@gmail.com> 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