[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[orbit-dev] Re: Orbit packages with versions]
|
That behaviour is defined by the OSGi spec and while that can be
discussed, it is not likely to change any time soon. Given that, the
"right" answer here is to work in Orbit to ensure that the various
bundles have proper version specs on the Export-Package statements.
There is some potential for this to be done automatically at build time
in a way similar to what we do with the .qualifier. For example, if you
spec a particular "replace me" version number on the export then the
version number is set to that of the bundle in the build.
As an importer you would define and maintain version ranges according to
your level of change tolerance.
This falls down somewhat because others in the world do not necessarily
apply the same semantics to version numbering so the change tolerance
specification inherent in version ranges may not get you what you
wanted. But in the end that problem is largely intractable anyway and
this would get us much of the way there.
Another point is to look at what they are doing over at Apache and
Felix. There has been a move there to bundle more libs so perhaps they
have a story that works.
Jeff
Christian Campo wrote:
maybe its just my view of the current problem I am facing but I
believe that setting no specific package version should
mean that it is the same as the bundle version. For me package version
is useful if you like to be more specific in
specific packages in your bundle. At least that is true for classes
that are located in the bundle. Probably its not true for packages
that you import and export again. Hmmm its gets trickier the more you
think about it.
Just setting it to 0.0.0 is not my prefered choice, because in the
import I'd like to specify a minimum version that is
not 0.0.0 but something higher. Does that require me to specify and
maintain a version for each package ?
christian campo
Jeff McAffer schrieb:
moving this over to orbit-dev so we can get the dev team's point of
view ...
Essentially we should be having versions on the export package
statements as much as possible. the key question is what the version
numbers should be and how do we figure that out. IMHO this should be
an Orbit-wide effort/policy to avoid churn.
As for whether or not the behaviour you are seeing now makes sense, I
believe that no version on export is the same as saying 0.0.0. If
you then import and spec no version then you are good. It would be a
good test to try importing with say [0.0.0,1.0.0) and see what happens.
Jeff
Christian Campo wrote:
Hi,
Riena uses two components that are maintained in Orbit that we have
slight problem with. One is org.apache.log4j and the other is
org.easymock. The problem is that the bundle specifies a bundle
version but the packages have no such version.
Now we have a pretty keen user of Riena (a very nice person
actually) who asked us the replace Require Bundle statements in our
manfest files with import package statements. We did that but found
out that Equinox or the PDE is not able to find a matching bundle if
we import the package with version number.
The reason seems to be that if the bundle exports a package and does
not specify a package version then it does not mean (as I would
assume) that the package version is the bundle version but it is no
version. So asking for a specific version of a package resolves to
no bundle found.
1. Is that a bug or a feature that packages with no version info
dont "inherit" the bundle version ?
2. I guess I have to bug the person who added the bundle to add the
package version info ? right ?
thanks
christian campo
------------------------------------------------------------------------
Subject:
Orbit packages with versions
From:
Christian Campo <christian.campo@xxxxxxxxxxxx>
Date:
Fri, 11 Jul 2008 14:04:14 +0200
Newsgroups:
eclipse.technology.equinox
Hi,
Riena uses two components that are maintained in Orbit that we have
slight problem with. One is org.apache.log4j and the other is
org.easymock. The problem is that the bundle specifies a bundle
version but the packages have no such version.
Now we have a pretty keen user of Riena (a very nice person
actually) who asked us the replace Require Bundle statements in our
manfest files with import package statements. We did that but found
out that Equinox or the PDE is not able to find a matching bundle if
we import the package with version number.
The reason seems to be that if the bundle exports a package and does
not specify a package version then it does not mean (as I would
assume) that the package version is the bundle version but it is no
version. So asking for a specific version of a package resolves to
no bundle found.
1. Is that a bug or a feature that packages with no version info
dont "inherit" the bundle version
2. I guess I have to bug the person who added the bundle to add the
package version info ? right ?
thanks
christian campo