With the recently-released OSGi Release 5 early access documents, one of the most anticipated features of the upcoming specification – that of SNAPSHOT style versions for OSGi – has been dropped from the specification because of concerns with existing tooling:
But the big concern come around interactions with existing tooling, management and provisioning systems. These systems would not understand a bundle having a pre-release version string. They would require a lot of changes to properly handle support the pre-release version syntax.
The problem stems from the differences between the way that Maven (and thus, Maven-compatible resolvers/build systems such as Ivy and Gradle) and the way that OSGi handle the empty qualifier are reversed. In Maven, 1.2.3.2012 <= 1.2.3, but in OSGi, 1.2.3.2012 >= 1.2.3.
This causes problems when building components which are able to work in both a non-OSGi environment (say, consumed with Maven) and with those destined to run inside an OSGi container. The convention, in Maven terms, is to work against (a number of) 2.1-SNAPSHOT builds, before finally replacing the version number as 2.1. Often a repository manager (such as Artifactory or Nexus) will rewrite the snapshots to a dated file when published for traceability.
Eclipse PDE build, and thus Maven Tycho, works by explicitly naming each built component, typically with a changing date/timestamp as part of the build. Since each built component gets a new name, the versions may be incrementally installed into an OSGi runtime with the new version overriding another.
Unfortunately, this means that the versions of the 'final' released components also contain a build qualifier, which can in some cases be longer than the name of the artifact itself (e.g. org.junit_4.8.2.v4_8_2_v20110321-1705). They also aren't consistent in the format of the qualifier (e.g. org.eclipse.jdt.ui_3.7.1.r371_v20110824-0800.jar ).
Some producers, such as SpringSource, create versions in the form 1.2.3.M1, 1.2.3.M2, 1.2.3.RELEASE which work for both OSGi and Maven consumption.
Supporting -SNAPSHOT style versions for OSGi would have solved this problem. It was proposed (and even implemented in Equinox) that the Bundle-Version syntax could have been upgraded to permit 1.2.3-456 to sort lower than 1.2.3. This could have enabled bundle developers to use the -SNAPSHOT style variant (with tooling like Tycho and PDE using -SNAPSHOT as the 'magic replacement value' instead of .qualifier) for development purposes, and then release 1.2.3 as the only build in that sequence, followed by a bump to 1.2.4-SNAPSHOT.
Unfortunately, the concerns raised were speculative rather than empirical:
Furthermore, we also become concerned about the mental complexity of pre-release versions. In numerous discussions within CPEG and with peers, people would get confused over the ordering of versions and whether some version was included in some range. If we, the "experts", couldn't keep it straight in our minds, we might expect others to also have a hard time.
The complication was related to how build ranges are concerned. Existing use cases such as [1.0,2.0) were considered. In this case, the 1.0 would have permitted snapshot 1.0-* versions, whereas the 2.0 at the other end would not. Ultimately, this rule boils down to If it's an inclusive range, it includes snapshots, and if it's a exclusive range it excludes snapshots which hardly seems difficult to recall.
The risk is that this decision actually dissuades the use of OSGi-generated content. For about a year, there have been discussions on how to represent the Eclipse-built artifacts in a Maven namespace, by mapping the components into an org.eclipse.* style group and with the full artifact name. However, the proposal has been to just drop all the qualifiers to make it easier for humans to consume, at least from the Maven front end.
This highlights a problem with the use-case of using a qualifier for everything. Developers forget to update the version number and just use the auto-generated number when providing builds, with the result that the Eclipse repository contains multiple artifacts with the same major/minor/patch version number, but different build qualifiers. From a local Eclipse 3.7 instance, upgraded to 3.7.2, the following are just a subset of the plugins with duplicate major/minor/patch versions:
- org.eclipse.cdt.codan.checkers.ui_1.0.0.201109151620.jar
- org.eclipse.cdt.codan.checkers.ui_1.0.0.201202111925.jar
- org.eclipse.core.filebuffers_3.5.200.v20110505-0800.jar
- org.eclipse.core.filebuffers_3.5.200.v20110928-1504.jar
- org.eclipse.core.variables_3.2.500.v20110511.jar
- org.eclipse.core.variables_3.2.500.v20110928-1503.jar
- org.eclipse.emf.ecore_2.7.0.v20110912-0920.jar
- org.eclipse.emf.ecore_2.7.0.v20120127-1122.jar
- org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110506.jar
- org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110815-1438.jar
- org.eclipse.equinox.p2.updatesite_1.0.300.v20110510.jar
- org.eclipse.equinox.p2.updatesite_1.0.300.v20110815-1419.jar
- org.eclipse.jdt.compiler.tool_1.0.100.v_B76_R37x.jar
- org.eclipse.jdt.compiler.tool_1.0.100.v_B79_R37x.jar
- org.eclipse.jface_3.7.0.I20110522-1430.jar
- org.eclipse.jface_3.7.0.v20110928-1505.jar
- org.eclipse.ltk.core.refactoring_3.5.201.r371_v20110824-0800.jar
- org.eclipse.ltk.core.refactoring_3.5.201.r372_v20111101-0700.jar
- org.eclipse.pde.runtime_3.4.201.v20110819-0851.jar
- org.eclipse.pde.runtime_3.4.201.v20110928-1516.jar
- org.eclipse.ui_3.7.0.I20110602-0100.jar
- org.eclipse.ui_3.7.0.v20110928-1505.jar
The problem is that these numbers are generally meaningless to anyone who looks at the file system or tries to remember the number. This may not matter if you're using a repository tool such as P2 or OBR to materialise your artefacts, but the majority of the world's build tools are still built upon a Require-Bundle type of dependency with an explicit version number and name. It also complicates management of many OSGi runtimes where an easy comparison of installed bundles becomes more difficult.
The -SNAPSHOT/release/-SNAPSHOT model solves this problem, because at promotion time the version number is explicitly incremented. (This doesn't rule out the possibility of doing a further testing stage after the version number has been finalised; but typically problems found at that stage lead to a bump in the patch level anyway.) This process is used successfully by the Apache Felix project who have a list of releases with short numbers and are easy to re-use in an existing build. Arguably it is easier to build against Apache Felix for headless OSGi builds than Equinox, both because of this and because the artifacts are available in Maven central already.
In InfoQ's opinion this is a missed opportunity. By not following through with the proposed implementation, based on minor concerns, the OSGi core platform expert group have turned a tooling problem into a human problem.
