WTP/Build/VersionChecker

Introduction

In WTP we use a utility application, informally called VersionChecker, that can be used during a build to compare the current set of bundle version numbers to some reference set of version numbers to make sure they follow the rules of versioning (they all "increase" in minor or service fields) from one release to another. We don't intend this to be API or a general purpose tools that fits all projects, but if other teams/projects would like to use it, add it it, fix bugs!, etc. feel free. But please do contribute back any improvements or fixes you make ... or, even, improve these brief directions so others could use them!

Note: in Eclipse 3.4 there are API tools that should help developers spot and correctly increment version numbers. API Tools also includes a set of ANT tasks that can be run in a Headless build. These tasks are included in the org.eclipse.pde.api.tools plug-in. Currently WTP still uses its own version checker. More information on API Tooling from PDE can be found in the API Tooling Introduction on Developer Works. The API Tooling ANT tasks are available in the Eclipse 3.5 Milestone builds, along with the documentation.

Code Location

Bundle/module name:

org.eclipse.wtp.releng.versionchecker

Repository:

https://git.eclipse.org/c/webtools/webtools.releng.git/

git clone ssh://${GITUSER}@git.eclipse.org:29418/webtools/webtools.releng.git

Module location:

https://git.eclipse.org/c/webtools/webtools.releng.git/tree/org.eclipse.wtp.releng.versionchecker

Brief outline of use

The reference data is currently kept in a master file in the versionchecker bundle, named referenceVersioningData.xml. Each set if reference data is in one element, referenceData, with a reference id attribute which is how subsequent tests find the data to compare.

[TODO: in practice, it'd help to have the ability to find reference data in a location independent of the bundle.]

Listing data:

There is one mode (application) of only listing data, org.eclipse.wtp.releng.versionchecker.listVersions. After all, you need at least one reference to compare to. In practice, the reference data file is generated every build, in case that is desired to become official reference data.

Comparing data:

There is another mode (application) to compare the current set of version numbers (in the environment that is running) with a specified set of reference data.

In practice, this can be used as a JUnit test with code similar to the following.

	public void testVersionCompare() throws Exception {

		VersionLister versionLister = new VersionLister();
		String[] args = new String[]{"countQualifierIncreaseOnlyAsError", 
                                "-testToReference", "WTP-3.0.2", "-listToReferenceFile"};
		Object result = versionLister.run(args);
		boolean testok = (IApplication.EXIT_OK.equals(result));
		assertTrue("There is an error in versioning. See full listing for details.", testok);

	}

During such a run of the test, there are several files created ... that are identified by the buildid:

versioningReference_3.0.2.xml
This is simply a listing of the current version numbers ... in a form that can be used as a future reference set. If that is desired, then the set of data in this file, must be copied into the master data file, referenceVersioningData.xml

versioningReport_3.0.2.xml
This is an actual report of the differences found. Also included are bundles that had do difference, bundles that are new, and bundles that are no longer in the current environment.

versioningReportToHTML.xsl
Not actually created, but exists in versionChecker bundle to produce an HTML form of the report. Can be customized or improved for better reports, naturally.

versioningReport_3.0.2.html
The versioning report in HTML form.