Add maven property for build qualifier

[tcornerstone]

The desired build qualifier can now be passed via command line and also includes the current date. Without any flags, the build qualifier defaults to "Alpha" and the current date.

Examples:

• mvn clean verify → "org.eclipse.tea.core_2.0.1.Alpha-202410171235.jar"
• mvn clean verify -Dqualifier=Beta → "org.eclipse.tea.core_2.0.1.Beta-202410171235.jar"
• mvn clean verify "-Dtycho.buildqualifier.format='Final'" → "org.eclipse.tea.core_2.0.1.Final.jar"

[haubi]

Just learned at OCX24: Instead of the build time stamp we should use the commit time stamp, and there is some tycho plugin for that.

But still I prefer do be able to append some extra info like "-pr42" via mvn commandline, to support something like these versioning schemes depending on who initiated the build, for seeing quickly when some non-release binary is used:

• 1.2.3.20241014170100: local, built by dev (as the default)
• 1.2.3.20241014170100-pr17: ci-build for some PR, built by Jenkinsfile
• 1.2.3.20241014170100: on merge to master, built by Jenkinsfile
• 1.2.3.20241014170100-release: on release creation, built by Jenkinsfile

[haubi]

@Bananeweizen Could you please give a hint on where to find that tycho plugin providing that commit timestamp?

Ah... when there are local changes in the workspace, I prefer to see a version number like:

• 1.2.3.20241024171800-dirty

Is that supported as well by that tycho plugin?

[Bananeweizen]

You need the upper half of the code shown in https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers. Adding a "dirty" part doesn't make much sense IMO, details for dirty workspace are on that wiki page. I rather recommend to fail the build for a dirty workspace, because that binary is absolutely not reproducible. If you install that binary somewhere and get an error later, you cannot go back to that code (as there is no commit).

If you need more things to be configured, https://github.com/git-commit-id/git-commit-id-maven-plugin would be my recommendation. But again, I would recommend to NOT put all this information into the qualifier (or generally the name of jars) at all. I suggest to rather inject the git variables from the commit id maven plugin into the about.properties, into feature.xml text, into the splash screen text, into the product file or similar. Then they are easily visible in the installation details, in the about dialog etc. and nobody has to "decode" jar names.

[haubi]

@Bananeweizen Thanks for those information and pointers!

So I understand this like having "reproducible builds" as the idea behind:
While we're not strictly there yet AFAICT, I can live with that idea.

But then, the idea of "reproducible builds" applies to commits that are pushed to the target branch only, or at least are persisted in another way - which does not necessarily apply to pull requests or even local commits.
Beyond that, non-automated builds are even less "reproducible", because also the build environment is kind of undefined.

In other words, only the automated builds (e.g. Jenkins Jobs, Github Actions) behind the master branch or even release tags (if necessary then) should create (and publish) binaries having the timestamp-only qualifier.
For local builds, as well as for automated builds behind pull requests, I really would like to have some indicator as part of that qualifier, indicating that the binary may not be reproducible because the commit may not be persistent, or the build environment was undefined.

To me, this is important because when testing some change by deploying that binary to some IDE or even application, forgetting about that, then returning back to that IDE or application after a while, wondering why something behaves strange, then looking at the installed version numbers should indicate there's something "unofficial" installed, without the need to look into installed content for lots of installed packages.

Or am I still missing something here?

[Bananeweizen]

Using jgit.dirtyWorkingTree it's possible to completely forbid builds with a non-committed tree. I use that strict setting in all our teams. Of course you can continue to allow and to handle non-reproducible builds, but in my eyes you are looking for a complicated solution to a problem which simply doesn't exist, if you also follow that pattern. In my teams the CI system is the only machine producing deployable artifacts, always the same way, and always storing all build outputs in an artifact management system, so nobody will ever install local builds. Removing a problem is far more simple than solving it.

[haubi]

Well... how do you handle pull requests then?
They are proper commits on the git level, and there is a CI system creating binaries, but still these commits are not necessarily persistent - and this is what I would like to indicate in that version number, because I would like to test pull requests in the final-like deployment scenario.