When a new version of the project is released, the plug-in and feature numbers need to be updated. This can be done manually, or by modifying the pom.xml
file and MANIFEST.MF
version numbers, or by running a tool to do this.
mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=1.2.3-SNAPSHOT
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
[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]
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 META-INF/MANIFEST.MF
(needed by Eclipse) and pom.xml
(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
(see http://semver.org), 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). While the major
/minor
/micro
versions are sorted numerically, 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, (1.2.3.build < 1.2.3.RELEASE
). They also use M1
, M2
, and 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.