When a new version of the project is released, the plug-in and feature numbers need to be updated. This can be done manually, by modifying the pom.xml and MANIFEST.MF version numbers, or by running the tycho-versions-plugin:set-version tool.
- From the parent directory, run (all on one line):
mvn org.eclipse.tycho:tycho-versions-plugin:set-version-DnewVersion=1.2.3-SNAPSHOT
- The output should say SUCCESS for the parent and SKIPPED for the others:
[INFO] Reactor Summary: [INFO] [INFO] com.packtpub.e4.parent .................. SUCCESS [5.569s] [INFO] com.packtpub.e4.clock.ui ................ SKIPPED [INFO] com.packtpub.e4.junit.plugin ............ SKIPPED [INFO] com.packtpub.e4.feature ................. SKIPPED [INFO] com.packtpub.e4.update .................. SKIPPED
- Now run a build to verify that the versions were updated correctly:
[INFO] Building com.packtpub.e4.parent 1.2.3-SNAPSHOT [INFO] Building com.packtpub.e4.clock.ui 1.2.3-SNAPSHOT [INFO] Building com.packtpub.e4.junit.plugin 1.2.3-SNAPSHOT [INFO] Building com.packtpub.e4.feature 1.2.3-SNAPSHOT [INFO] Building com.packtpub.e4.update 1.2.3-SNAPSHOT [INFO] Reactor Summary: [INFO] [INFO] com.packtpub.e4.parent .................. SUCCESS [0.001s] [INFO] com.packtpub.e4.clock.ui ................ SUCCESS [0.561s] [INFO] com.packtpub.e4.junit.plugin ............ SUCCESS [0.176s] [INFO] com.packtpub.e4.feature ................. SUCCESS [0.071s] [INFO] com.packtpub.e4.update .................. SUCCESS [2.764s]
- Finally, once the development is complete, build with a release version:
mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=1.2.3.RELEASE
The Tycho set-versions plugin is very similar to the Maven version:set plugin; however, Tycho makes changes for both the META-INF/MANIFEST.MF file (needed by Eclipse) and the pom.xml file (needed by Maven).
Development version numbers in Maven end in -SNAPSHOT to indicate that they are a mutable release, and there's special handling in Maven builds to get the latest snapshot build. For Eclipse builds, the equivalent special name is .qualifier, which is appended onto the end of the plug-in and feature builds.
For simple projects, where there is a single plug-in and feature, it can often make sense to have the two versions kept in sync. Sometimes, when there are two highly related plug-ins in the same feature (for example, JDT and JDT UI), then it can also make sense in keeping them in sync. For larger projects where a single build may have multiple modules, it can make sense to have different version numbers on a plug-in by plug-in basis.
The version numbers in OSGi and therefore Eclipse plug-ins follow semantic versioning, in which the version number component consists of a major version, a minor version, and a micro version, as well as an optional qualifier. The major, minor and micro versions default to 0 if not present, while the qualifier defaults to the empty string. Typically, the qualifier is used to encode either a build timestamp or a build revision identifier (such as that produced by git describe on modern version control systems). The major/minor/micro are sorted numerically, but the qualifier is sorted alphabetically.
Unfortunately, OSGi version numbers and Maven version numbers differ in agreement on what the highest value is. For Maven, the empty qualifier is the highest (that is, 1.2.3.build < 1.2.3), whereas for OSGi it is the other way around (1.2.3.build > 1.2.3). As a result, organizations such as SpringSource have created a de-facto policy of using a qualifier of RELEASE to indicate the release build, since 1.2.3.build < 1.2.3.RELEASE. They also use M1, M2, M3 for milestone releases and RC1, RC2 for release candidates, since all of these are less than RELEASE. As a result, the progression for Eclipse build qualifiers tends to follow -SNAPSHOT, M1, M2, RC1, RC2, RELEASE.
Apply the same pom.xml builds to allow the other plug-ins built in the other chapters as part of the automated build. This includes the headless application (the product can be moved into the same product) and the Minimark editor. The standalone JUnit test will need to be built as a jar instead of an eclipse-plugin, and examples are available at the Maven homepage or the book's GitHub repository.