Eclipse Community Forums: Orbit » Orbit packages with versions]

Help

Home

Home » Eclipse Projects » Orbit » Orbit packages with versions]

Show: Today's Messages :: Show Polls :: Message Navigator

Orbit packages with versions] [message #13300]

Tue, 15 July 2008 12:42

Christian Campo

Messages: 597
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------060001080305020201020704
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------060001080305020201020704
Content-Type: message/rfc822;
name="Orbit packages with versions.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Orbit packages with versions.eml"

Path: build.eclipse.org!not-for-mail
From: Christian Campo <christian.campo@compeople.de>
Newsgroups: eclipse.technology.equinox
Subject: Orbit packages with versions
Date: Fri, 11 Jul 2008 14:04:14 +0200
Organization: EclipseCorner
Message-ID: <g57i80$66g$1@build.eclipse.org>
NNTP-Posting-Host: frankfurt.compeople.eu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: build.eclipse.org 1215777856 6352 80.153.43.238 (11 Jul 2008 12:04:16 GMT)
X-Complaints-To: news@build.eclipse.org
NNTP-Posting-Date: Fri, 11 Jul 2008 12:04:16 +0000 (UTC)
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
Xref: build.eclipse.org eclipse.technology.equinox:4905

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

--------------060001080305020201020704--

Report message to a moderator

Re: Orbit packages with versions] [message #13328 is a reply to message #13300]

Tue, 15 July 2008 19:22

Eclipse User

Originally posted by: jeff.code9.com

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@compeople.de>
> 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

Report message to a moderator

Re: Orbit packages with versions] [message #13371 is a reply to message #13328]

Tue, 15 July 2008 22:08

Christian Campo

Messages: 597
Registered: July 2009

Senior Member

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@compeople.de>
>> 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

Report message to a moderator

Re: Orbit packages with versions] [message #13391 is a reply to message #13371]

Wed, 16 July 2008 06:48

Christian Campo

Messages: 597
Registered: July 2009

Senior Member

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@compeople.de>
>>> 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

Report message to a moderator

Re: Orbit packages with versions] [message #563886 is a reply to message #13300]

Tue, 15 July 2008 19:22

Jeff McAffer

Messages: 104
Registered: July 2009

Senior Member

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@compeople.de>
> 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

Report message to a moderator