[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[orbit-dev] Re: Orbit packages with versions]
|
I am posting it again because it didnt appear on orbit-dev the first time (I had no user there)...
sorry for duplicate posting in the mailing list
christian campo
Christian Campo schrieb:
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
