I switched to Eclipse 3.3 for fun (and the T-shirt was tempting too), and banged into my first obstacle. Now the four digits scheme is strictly enforced for the version numbers.
That’s ok with me, I just changed the version numbers to add one more ‘.’ somewhere.
The thing is… our build system adds the build number as a new token.
So when building my new artifact, I had a version like this 1.0.0.0.001. That’s quite ugly. Well, I didn’t put too much attention into it.
Then switching to Eclipse 3.3 would not happen.
Here is the stacktrace you get when trying to activate a plugin with 5 tokens:
org.osgi.framework.BundleException: Exception in org.eclipse.update.internal.configurator.ConfigurationActivator.start() of bundle org.eclipse.update.configurator. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118)
with a nested stacktrace:
Caused by: org.eclipse.core.runtime.CoreException: Cannot create configuration in file:/home/atoulme/eclipse/configuration/ at org.eclipse.update.internal.configurator.Utils.newCoreException(Utils.java:96) at org.eclipse.update.internal.configurator.ConfigurationActivator.initialize(ConfigurationActivator.java:111) at org.eclipse.update.internal.configurator.ConfigurationActivator.start(ConfigurationActivator.java:69)
with a root exception:
org.eclipse.core.runtime.CoreException: Cannot create configuration in file:/home/atoulme/eclipse/configuration/ at org.eclipse.update.internal.configurator.Utils.newCoreException(Utils.java:96) at org.eclipse.update.internal.configurator.ConfigurationActivator.initialize(ConfigurationActivator.java:111) at org.eclipse.update.internal.configurator.ConfigurationActivator.start(ConfigurationActivator.java:69) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method)
Ordinarily, having a stacktrace means you already won. You just have to go at the right line of code, fix the problem and get the thing running.
In this case, the bundles that were throwing the exception are completely out of the Eclipse SDK workspace code, so the only option I had was to go look at it on cvs.
I ended downloading the code, compiling it in my 3.2.2 workspace and add a line in the getPlatformConfiguration() method.
**
* Creates and starts the platform configuration.
* @return the just started platform configuration
*/
private PlatformConfiguration getPlatformConfiguration(URL installURL, Location configLocation) {
try {
PlatformConfiguration.startup(installURL, configLocation);
} catch (Exception e) {
System.err.println("THERE WAS AN EXCEPTION" + e);
e.printStackTrace();
if (platformTracker != null) {
String message = e.getMessage();
if (message == null)
message = ""; //$NON-NLS-1$
Utils.log(Utils.newStatus(message, e));
}
}
return PlatformConfiguration.getCurrent();
}
Suddenly, I had the right stacktrace popping up:
THERE WAS AN EXCEPTIONjava.lang.IllegalArgumentException: invalid format
java.lang.IllegalArgumentException: invalid format
at org.osgi.framework.Version.(Version.java:143)
at org.osgi.framework.Version.parseVersion(Version.java:209)
at org.eclipse.update.internal.configurator.VersionedIdentifier.(VersionedIdentifier.java:21)
Please look at the constructor of the Version class if you want to know more on the version string parsing. It says it better than an hundred words.
I hope this helps people migrating to Eclipse 3.3. I am 100% guilty of not respecting the OSGi standard (and I am now running to get this all fixed, and up and running with the latest RC!).
I opened a bugzilla entry to report this hidden stacktrace, feel free to comment it!
Eclipse has guidelines for version numbering that I can recommend for you: http://wiki.eclipse.org/index.php/Version_Numbering
oh thanks, I was still hanging to this one:
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg00301.html
Note that OSGi only supports 3 numeric identifiers; the 4th one is textual. So if you have 1.2.3.10, that’s less than 1.2.3.4.
Bottom line: only use 3 numeric identifiers, and start the 4th with an alphabetic, even if you’re going to include numeric/date version information there to make it clear it’s not numeric.
alex.
Agreed — use something alphabetic for the 4th part. However, nothing stops you from doing something like 1.0.0.v200706251234, which not only adds more information (a datestamp) than 1.0.0.foo, but also guarantees that integration builds in a branch will be able to install on top of older ones (and the Update Manager wizard will respect that too).
I think all the bugs around use of “_” in qualifiers have been squashed by now, but just in case I recommend avoiding the use of underscores in favour of dashes, thus: 1.0.0.v200706251234-something-else-useful-here.
Thanks guys, I will keep that in mind for the next builds. For now keeping a build number a la SWT makes more sense to us. In time we’ll switch gently.