Bug 571751 - [tycho-versions-plugin] Allow Maven CI-friendly versions

[chrhuff]

Copied from: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571751

I have been attempting to introduce Maven CI-friendly versions to a Tycho multi-module project.

With a version like this:

<version>${revision}${changelist}</version>

and two additional properties in parent POM:

<revision>1.0.0</revision>
<changelist>-SNAPSHOT</changelist>

A regular mvn clean install works as expected, as the version defaults to 1.0.0-SNAPSHOT. However, if a release version is to be created, by clearing the changelist, the Bundle-Version does no longer match, as it bears the .qualifier.

Bundle-Version: 1.0.0.qualifier

This is - correctly - detected by tycho-packaging-plugin:

mvn org.eclipse.tycho:tycho-packaging-plugin:2.2.0:validate-version -Dchangelist=
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.2.0:validate-version (default-cli) on project tycho.demo.itp01: Maven version 1.0.0 must have -SNAPSHOT qualifier for SNAPSHOT builds -> [Help 1]

Usually, one would use tycho-versions-plugin to automatically sync versions. However, this does not work as expected:

mvn org.eclipse.tycho:tycho-versions-plugin:2.2.0:update-eclipse-metadata -Dchangelist=
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-versions-plugin:2.2.0:update-eclipse-metadata (default-cli) on project parent: Execution default-cli of goal org.eclipse.tycho:tycho-versions-plugin:2.2.0:update-eclipse-metadata failed: Invalid version: 
[ERROR]   Version ${revision}${changelist} is not valid for /home/chrhuff/git/org.eclipse.tycho-demo/itp01/tycho.demo.itp01/META-INF/MANIFEST.MF
[ERROR] -> [Help 1]

This can be reproduced using the Tycho Demo project (org.eclipse.tycho-demo/itp01), from my public GitHub repository.

It appears to me that tycho-versions-plugin does not evaluate project.version properly, whereas tycho-packaging-plugin does.

A potential, but clumsy (and untested) workaround is to a) configure validate-version to not break the build b) use flatten-maven-plugin to create .flattened-pom.xml files (which is required if you want to deploy artifacts, anyway, as documented by 1) c) invoke tycho-versions-plugin using -f .flattened-pom.xml on each individual module d) repeat the build (without -f)

A long-term solution could also decouple the source from the build target version in target/MANIFEST.MF, so the dynamically resolved version from Maven is used, regardless of the version in META-INF/MANIFEST.MF and other eclipse-related files.

[mickaelistria]

I imagine that we could instead let the tycho version force a qualifier. Instead of failing with Maven version is x.y.z.123456 and version in MANIFEST.MF is x.y.z.qualifier, the validate version could instead set forceQualifier=123456. In most cases, that would work, in other cases where there are inconsistencies, further steps such as packaging-plugin baseline replacement or compare-with-baseline would fail.

[mickaelistria]

As we're brainstorming in many other discussions about better integrating with plain Maven, I'm wondering whether Tycho can better leverage this "CI-friendly" versions in place of the qualifier/-SNAPSHOT. Mainly, I'm wondering: can the revision or sha1 or whatever variable allowed in <version> be set in project intiialization? More concretely, would it be possible for Tycho to dynamically set eg. sha1 according to the current module last change date in git history? Could the step is usually run to set the qualifier property be run early enough to set the sha1 property and have this expanded in the Maven version?

[laeubi]

Why not? The jgit timestamp provider already do some stuff to compute the qualifier. But if I understand correctly it is assumed that the version is set by the CI server or commandline or ... already and the only real change is that one could use these magic properties inside version string.

I think the main problem is thatversion in manifest = version in pom constraint. I could imagine that we simply make it that instead of fail the build add an option to replace the version in the manifest with the version from the maven model. This of course would require a user to not use hard versions in feature/manifest but version ranges but I think this is acceptable (one should version packages not bundles).

[mickaelistria]

Why not?

I'm not certain, but I have the impression that those specific properties in version need to be resolved very early in the lifecycle; ie in model build, before any plugin is executed. So before we have a hook where to add the jgit-timestamp-provider. Or maybe we can hook some extra execution before model build using the extension...?

I think the main problem is that version in manifest = version in pom constraint

It wouldn't hurt to have an option (opt-in) in the https://www.eclipse.org/tycho/sitedocs/tycho-packaging-plugin/validate-version-mojo.html that would allow 1.0.0 in MANIFEST.MF to be an acceptable match for 1.0.0-SNAPSHOT in pom files. It should remain an opt-in because the behavior of generating multiple artifacts with same qualified version and different content is a strong anti-pattern, and the qualifier is used to avoid that; and Tycho should encourage best approaches by default.

that instead of fail the build add an option to replace the version in the manifest with the version from the maven model?

Note that usually, there is no qualifier segment in the Maven model version. So there is usually not enough for Maven to "drive" a qualifier. However, in case one uses 4-segments versions in the Maven model, it could indeed be an option to the https://www.eclipse.org/tycho/sitedocs/tycho-packaging-plugin/build-qualifier-mojo.html to deduce qualifier from Maven 4th-segment if available.

[laeubi]

Tycho now support CI-Friendly versions see: https://github.com/eclipse/tycho/blob/master/RELEASE_NOTES.md#enhanced-support-for-maven-ci-friendly-versions Please open specific issues if you still see problems.