Re: [orbit-dev] Re: Orbit packages with versions]

[Thomas Watson <tjwatson@xxxxxxxxxx>]

We have a similar issue in the Execution Environment profiles included in the org.eclipse.osgi bundle (the *.profile files). These files define the list of packages provided by the various well known VM Execution Environments for the Java Platforms (J2SE-1.4, JavaSE-1.6 etc). These packages end up being exported by the system.bundle (org.eclipse.osgi) at runtime. The problem is I have not found any definitive document that states the list of packages and their versions that must be included in a VM in order for it to be called J2SE-1.4, J2SE-1.5 etc. As a result all of these packages are exported with 0.0.0 versions. (e.g. org.w3c.dom, javax.xml.parsers etc.)

This really hinders our consuming bundles from using Import-Package with versions to get these packages. If a version is specified then it will force another bundle to be installed that exports the package with the appropriate version even though the Execution Environment may actually have an appropriate version.

I have asked this question on several lists and have gotten no responses, so I will try again. Does anyone know where I can find a definitive list of packages AND versions that must be included in a VM for each Java Platform release?

Tom



Jeff McAffer ---07/15/2008 02:23:47 PM---moving this over to orbit-dev so we can get the dev team's point of view ... Essentially we should b

From:	Jeff McAffer <jeff@xxxxxxxxx>
To:	"orbit-dev@xxxxxxxxxxx" <orbit-dev@xxxxxxxxxxx>
Date:	07/15/2008 02:23 PM
Subject:	[orbit-dev] Re: Orbit packages with versions]

---

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
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev