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<[email protected]> 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<[email protected]>
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<[email protected]> wrote:
That is probably because the proxy pom.xml which defines the version
of proxy-api to depend on has 0.4-SNAPSHOT in it. If it was
0.3-SNAPSHOT you would get the right version range.
Alasdair
On 8 February 2011 15:53, zoe slattery<[email protected]>
wrote:
Hmm - well - I reverted my change and actually the range for the
import was
wrong before. My changes made no difference, but I do agree that it
needs to
be fixed and will work on it.
Zoe
Well, I think the result is plain wrong.
For example proxy/proxy-impl imports the org.apache.aries.proxy
package with a [0.4,1) range.
However, given it implements the spec, the semantic versioning
guidelines indicates that the range should be [0.4,0.5).
On Tue, Feb 8, 2011 at 16:03, zoe slattery<[email protected]>
wrote:
OK - I have checked in a change under
https://issues.apache.org/jira/browse/ARIES-571 which reverts the
dependency
between Aries modules.
I have checked that import ranges are calculated correctly by the
maven
bundle plugin. The range is now based on the version of the
dependency.
So, for example, a module that depends (as a consumer) on
util-0.4-SNAPSHOT
will import util packages in the range [0.4, 1.0). A module that
depends
on
util-0.3 will import util packages in the range [0.3, 1.0).
Everything builds and all the tests run.
Zoe
Actually, after thinking about it, I don't think there's much
problem.
So please go ahead.
We also need to make sure about the versions range we use for
imports,
i.e. up to the next major for a used package, and up to the minor
version if the package is implemented somehow. BND is supposed to
do
that automatically now, but we'd have to double check.
Also, if we keep old versions for dependencies, we'd still need to
test with recent ones I think, so not sure how to deal with that.
On Mon, Feb 7, 2011 at 15:38, Guillaume Nodet<[email protected]>
wrote:
I think the original code did not use version ranges and early
version
of maven bundle plugin did not allow for policies on creating
ranges.
That can be change if needed obviously.
Before doing any breaking changes in the way we release / version
packages or bundles, can we continue the discussion and have a
clear
picture where we are going to ?
There's no need to do the work multiple times, so if you're gonna
break that link, what do you plan to put instead ?
On Mon, Feb 7, 2011 at 15:31, zoe
slattery<[email protected]>
wrote:
Hi
There is something that I would like to change in the way we
build
Aries.
I'm asking because I don't really understand why it is there in
the
first
place.
Today, if I am building blueprint at version 0.4-SNAPSHOT, the
blueprint
bundle manifests which are generated all import versions of
other
aries
components in the range [0.4, 1.0). This is true even if I
modify a
blueprint pom to explicitly depend on, say
org.apache.aries.proxy at
version
0.3.
The import range is calculated (by some logic in the default
parent
pom)
in
a way that creates a tie between all of the aries components, it
also
overrides the default behaviour of the maven bundle plugin which
calculates
import ranges based on the version of the dependency.
In some cases I notice that people have worked around this
behaviour
by
hard
coding import ranges in the pom, see for example,
https://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-core/pom.xml
and the way that it imports org.apache.aries.quiesce.manager.
I would like to remove the logic from the default parent pom
that does
this.
However - I don't understand why it is there in the first place,
can
anyone
explain?
Zoe
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Alasdair Nottingham
[email protected]
