CI friendly versions: Cannot alter releaseVersion

[tja-m]

Following the samples I found, I tried to setup a simple experimental scenario to try CI friendly versions using Tycho 4.0.0-SNAPSHOT.

As POM version I defined <version>${releaseVersion}${qualifier}</version>, the default values of the corresponding build properties were defined as:

    <properties>
        <releaseVersion>1.0.0</releaseVersion>
        <qualifier>-SNAPSHOT</qualifier>
    </properties>

As the manifest property Bundle-Version is mandatory (and no variables seem to be accepted here) I defined it as

Bundle-Version: 1.0.0.qualifier

When I try to set a different releaseVersion on the command line

mvn package -DreleaseVersion=1.0.1

I get an error:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:4.0.0-SNAPSHOT:validate-version (default-validate-version) on project org.test.tjam.tycho.cifriendly.test.plugin1: Unqualified OSGi version 1.0.0.qualifier must match unqualified Maven version 1.0.1-SNAPSHOT for SNAPSHOT builds -> [Help 1]

Is there any other way to define Bundle-Version in the manifest, which allows choosing version property values at build time? Keeping versions out of the source code and having them injected by the CI build is the main point of CI friendly builds.

[laeubi]

In OSGi you usually use Semantic Versioning, so setting the bundle version to your releaseVersion is usually bad as you potentially create the same content with different versions.

So you have two choices regarding your setup:

1. Use pomless builds, then your pom version is always the manifest version you change whenever something changes
2. Use different versions in pom and manifest, then you need to disable the validate-version check but migth still produce "useless" versions in the pom domain but at least your OSGi version stays constant

So it depends a bit on what you want to archive here what is the best setup/choice.

[tja-m]

Thank you for your reply.

You may call it a drawback of CI friendly versions to obtain the same content with different versions in successive builds. Nevertheless this is, what CI friendly builds is about: Keep versions of artifacts to be built out of the source code and inject them from the CI build. The situation is the same for versions of POMs as it is with Bundle-Version in the manifest.

The issues you have with versions in source code in context of CI had been nicely discussed in Maven Release Plugin: Dead and Buried and its predecessors.

So I would go with option 2. I tried with -Dtycho.strictVersions=false which made the build work with a warning about the mismatch. Is there a way to completely disable the validation as part of packaging and avoid that warning in build logs?

BTW: Even with CI friendly version you can use semantic versioning by injecting semantic versions from the CI into your Maven build. Typically this is done for release builds only. In this case you have a set of sources, which is handled by a common CI build. All contained modules obtain the same version, even if some of them didn't change.

Only for "pure" continuous integration / delivery ... the distinction of snapshot builds and release builds does not make sense anymore, so you more or less have only build numbers left, which of course differs from semantic versioning.

[dhendriks]

I don't know if this is exactly what you want, but in Eclipse ESCET we use this:

            <!-- Configure packaging of JARs. -->
            <plugin>
                <groupId>org.eclipse.tycho</groupId>
                <artifactId>tycho-packaging-plugin</artifactId>
                <version>${tycho.version}</version>

                <configuration>
                    <!-- Use property-based fixed qualifier for all plugins/features/etc. -->
                    <forceContextQualifier>${escet.version.qualifier}</forceContextQualifier>
                </configuration>
            </plugin>

We have other ways to set the major/minor versions, but the qualifier is fixed during the build. We pass the qualifier via the property to Maven on the command line in the Jenkinsfile. This works well.

One reason we need this, is that we have plugins that take files from other plugins during the build. We therefore can't rely on e.g. Git timestamps and use a global qualifier for all plugins during a single build.

[tja-m]

Not the same situation but has similar aspects: With CI friendly version you inject versions too, but not only for the qualifier but for the complete version info.

Ans also the background is similar: Typically there are multiple components which are kept in a common Git repository and which are developed and built together and which obtain a common version identifier. In case the components have interdependencies, they have to refer to each other. CI friendly versions help keeping things consistent here. They also help in making merges between branches easier.

[laeubi]

As said keeping versions in sync just because it is "easier" produces very bad OSGi bundles, because versions have a meaning, also there are not only bundle-versions but more important package versions that describe your contract, so if your build / application only works if all and everything is build at the same version your contract is most probably not very well designed.

OSGi was build to decouple components not to make them coupled.... Still you can of course do it that way, but don't expect you gain anything from it.

As @dhendriks has described the CI friendly versions in Tycho are mostly for keeping the qualifier in sync (or remove it for a release), so one would usually keep the release version as is, and maybe update it for the parent pom (so it is automatically picked up at the childs as well), and only set the qualifier to a given value for the release.

Nerveless it would be possible to make Tycho to update the version in the manifest as well, but then you will see issues in your IDE as your local developed bundle suddenly will be assumed older than a release bundle if you not update the version.

So for a setup like you described, it would be better to use the tycho-version-plugin as it will increase the version in the pom and manifest accordingly, still you have to maintain the package-versions then to help your consumers understand if there are a chance for real breakage or they need to update anything.

[tja-m]

If a set of components is developed together, handled in a common source code repository and a common CI build, it is not bad design to use common version identifiers but the reasonable thing to do. As far as I understood the same thing happens for Tycho itself. The tycho-version-plugin is a possible workaround, but actual CI friendly versions are the better solution for this (I again recommend Maven Release Plugin: Dead and Buried and the predecessor posts on this. And I agree with Axel, that version identifiers do not belong in the source code repository, when using CI).

The OSGI design you refer to is interesting for components, which evolve independently. But this is a different situation.

Keeping only qualifiers in sync is another use case, but is way less than, what is targeted by CI friendly versions in Maven and what is required for modern enterprise applications, which rely on continuous deployment.

Nevertheless, your suggestion to disable the validate-version made my build work and will hopefully allow working with actual CI frienly versions. So thank you again :-)

[laeubi]

Tycho itself is not OSGi bundles (even though some still has OSGi headers for historic reasons) and do not expose any API, so the situation is a bit different here. Also maven lacks support for having mixed versions resolved automatically and you always have to specific exact versions.

So for OSGi the same version is not a requirement for "modern enterprise applications, which rely on continuous deployment", nerveless Tycho at the moment only enhances what maven offers, so CI Friendly Versions work on the maven level and usually the qualifier is used for identify individual builds on the bundle level.