Because of the namespace issues raised earlier there may be a much
The Orbit bundle com.google.inject already diverges in name from
So when a revised perhaps org.eclipse.orbit.guice is provided it can be
version 1.2, and
com.google.inject version 2.0.1 can be trimmed to a backwards
On 15/06/2010 15:09, Thomas Watson wrote:
We had a similar issue in Galileo with org.eclipse.osgi (Equinox)
exporting the wrong version for the org.osgi.util.tracker package. In
this case it was only a micro version that was incorrect (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=279622).
It was deemed too risky to all of a sudden lower the version of the
exported package at the end of the Galileo release. It was even too
risky for a point release. Instead we did "fix" it in Galileo SR1 by
exporting the package twice (once at the incorrect version and once at
the correct version).
In our case it was not so dramatic because there was only a difference
between version 1.4.2 and 1.4.0. In your case we are talking about
going from package version 2.0 to 1.2. This has far greater semantic
differences and I am not sure there is much we can do to fix this at
this point. I suggest you consider exporting the package twice (once at
the incorrect 2.0 version and once at the correct 1.2 version) in SR1
and allow consumers to migrate to importing the correct version. Then
in Indigo you can make the change to drop exporting the 2.0 version. If
that proves to be problematic you can always have a compatibility
fragment that can be added to export the 2.0 version.
Wagenknecht ---06/15/2010 01:01:04 AM---Greetings fellow Orbit
committers and Cross-Project readers,
Greetings fellow Orbit committers and Cross-Project readers,
The Google Guice bundle in Orbit (com.google.inject) exports all of its
packages as version 2.0. However, this is incorrect and has been changed
to version 1.2 in Orbit CVS. The fix is committed but not released.
For details please have a look at:
If you import com.google.inject[.*] packages, please modify your bundles
to *not* import a specific version. This will ensure that your bundles
will not require any modification once the fixed bundle will be
Is there anything we can do to Helios to *not* have the wrong bundle go
out? I think it's too late. I also suspect that the number of consumers
is very low across the train (<=3). The fixed bundle still has a
bundle version. Therefore, p2 should upgrade systems fine. Thoughts?
orbit-dev mailing list
cross-project-issues-dev mailing list
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.829 / Virus Database: 271.1.1/2939 - Release Date: 06/15/10 07:35:00