On 6/19/09 10:28 AM, Guillaume Nodet wrote:
On Fri, Jun 19, 2009 at 15:42, Richard S. Hall<[email protected]> wrote:
On 6/19/09 7:57 AM, Guillaume Nodet wrote:
I think we have two different use case for a bundle importing /
exporting the same package.
I think the first use case is when you have two different
implementation of a given service. If each service bundles its api,
you'll end up with multiple bundles exporting the same package with
the same version. In such a case, I think it makes sense to choose
to wire to an external bundle.
The second use case is when you have two different packages exported
with different versions. I think in such a case, felix should choose
the internal package rather than an external.
Not sure I understand this second case.
This is the use case I expressed in my first email, when you have two
bundles, each one exporting its own different version of package a.
This is a usual case when you simply deploy the same library in two
different versions.
Let's assume that those libraries follow the usual best practices (at
least those I know about, but correct me if i'm wrong).
I create a library and use bnd to generate the manifest.
So I use the following instrutions:
<Import-Package>*</Import-Package>
<Export-Package>foo;version="1.0"<Export-Package>
<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
This generates the following headers:
Import-Package: foo;version="[1.0,2.0)"
Export-Package: foo;version="1.0"
To be clear, if you are just creating a library, then you shouldn't
import the packages too...it makes no sense. But if you are a service
impl, for example, packaging the service API with you, then you should
do both.
If I create a 1.1 version of the same library using the same rules,
the headers will become:
Import-Package: foo;version="[1.1,2.0)"
Export-Package: foo;version="1.1"
Now, it means if i have already installed the 1.1 version of my
library, i won't be able to use the 1.0 version at all, because the
package will not be exported.
Not precisely correct. Given certain circumstances, you won't be able to
use it.
I would understand that the bundle importing the library would always
be wired to the 1.1 version unless it has a specific constraint to
1.0, but this constraint could not even by fullfilled because the
older package is completely hidden.
Maybe the problem come from a misconception, and that importing the
package you export is actually not a good practice when this package
is more an implementation package rather than an api package. Or
maybe the problem is that you need to always import the exact same
version (without range) that you export.
Yes, I think that is it, which is what I am saying above. If you do not
expect there to be multiple implementers of your package or you are just
a library bundle (i.e., no activator) or you do not expect good
backwards compatibility, then you should not import what you export or
do so only with a limited version range.
In all cases, I'd like the maven bundle plugin to do it the right way
by default and avoid users running into problems. I guess I just need
to understand what is the right way ;-)
Yes, I agree. Not sure if it can easily tell the difference between
these cases, though.
-> richard
-> richard
On Fri, Jun 19, 2009 at 13:59, Richard S. Hall<[email protected]>
wrote:
The seems fairly clear on this. A version like "1.0" is a range from 1.0
to
infinity. All things being equal, the resolver is supposed to select the
highest matching version, which is what happens here.
There is some wiggle room since the spec does allow the framework to
choose
when a bundle should export or import in this case, but favoring import
seems to make sense to reduce the number of inconsistent class spaces.
Otherwise I would say the bundle metadata is in error.
-> richard
On 06/19/2009 07:39 AM, Guillaume Nodet wrote:
Let's say we have two bundles
foo-1.0:
Export-Package: a;version="1.0"
Import-Package: a;version="1.0"
foo-2.0:
Export-Package: a;version="2.0"
Import-Package: a;version="2.0"
In felix (trunk), if you install foo-2.0, then foo-1.0, you end up with:
foo-2.0:
Export-Package: a;version="2.0"
foo-1.0:
Import-Package: a;version="2.0"
This really looks ackward (and will mostly lead to failures if the
major versions are not really compatible), though I haven't seen
anything in the core spec to forbid this.
Section 3.7 says that the resolution for foo-1.0 should either choose
an external package (which is what done here) or an internal package.
Equinox seems to handle it using an internal package.
What would you think about changing the resolution algorithm so that
it try to use an internal package instead of an external package if
all the constraints are met ?
