Background

I have some code that takes a list of .hpi files on disk and builds a temporary throw-away update centre in a docker image providing those plugins. In order to ensure interoperability with other update centres, it needs to parse versions the same way that Jenkins does, namely by reading the Plugin-Version manifest entry.

I then have some acceptance tests for my plugins that fire up a clean Jenkins instance, configure this update centre and download and install the plugin, thereby verifying the installation experience for new users.

I am following Continuous Delivery using the model where the Maven Release Plugin creates the release but I do not push changes back to master, instead I push the tags *after* the acceptance tests pass (thus the tags only reflect actual releases) and furthermore, I drop the Nexus Staging repo if the acceptance tests fail.

Because the release poms are never pushed back to master, the version in the pom.xml on master is *always* 1.x-SNAPSHOT

I now want to write acceptance tests to verify upgrades from specific known versions. Additionally when testing locally, I have a need to update the development builds of the plugin.

While I could just manually upload the plugins, this would not reflect the real user experience.

I need a way to modify the plugin's generated manifest and substitute the Plugin-Version for my own plugin version.

Proposed solution

Add a snapshotPluginVersionOverride configuration option to the hpi goal. This would be the version to set in the Plugin-Version manifest entry *but only in the case where the project.version is actually a -SNAPSHOT version*