deferring-maven-plugin

Overview

This Maven plugin is intended to allow calling mvn deploy:deploy independently of the Maven call triggering the packaging. This is interesting for use cases where some steps should be performed between packaging and deployment, like e.g. tagging a version in a release case.

Background

Packaging Mojos, like e.g. the maven-jar-plugin or the maven-war-plugin, are adding the information to the maven build context which artifacts where generated by the maven build and should be deployed in a later step. Maven keeps this information only in memory. If the maven-deploy-plugin is called in a later step independently, e.g. using mvn deploy:deploy, it's missing the information which artifacts where built. The deployment will fail (see maven-deploy-plugin FAQs)

In a multi-module-scenario each module is processed and deployed one after the other. This can lead to inconsistencies within the artifact repository e.g. when submoule A was build and deployed sucessfully, but the build of submodule B failed and therefore no new version of B was deployed. This can be addressed by the deploy-at-end experimental feature, but it's not enabled by default.

Another use case where deployment is decoupled from build and test is described by the unleash-maven-plugin covering the release process: to ensure that artifacts are only deployed if all steps within the release (changing versions, committing, builing, testing, tagging) were carried out successfully deployment is not handled within the maven call taking care about the packaging. Instead it's triggered at a later point in time.

While this issues could be overcome to configure which artifacts should be deployed when and where e.g. within build jobs on a CI server is might still be desireable to keep this information with the project in the pom.xml.

This plugin is intended to allow triggering mvn deploy:deploy independently of the Maven call triggering the packaging by providing two goals to write the context information about the artifacts to deploy out into the build directory after packaging and reading this context information from there again before deployment.

Usage

A typical use case could look like this

• Call mvn verify bayern.meyer.maven.plugins:deferring-maven-plugin:0.0.1:save-artifacts to serialize the information about which artifacts where packaged into a file deferring-maven-plugin.json
• Do something in between
• Call mvn bayern.meyer.maven.plugins:deferring-maven-plugin:0.0.1:load-artifacts install:install deploy:deploy to read the stored information and use it to install and deploy the generated artifacts

Goals

• save-artifacts: Serialize the information about the artifact version of the current run and which artifacts where packaged into a file deferring-maven-plugin.json
• load-artifacts: Read the stored information from the file deferring-maven-plugin.json and add it to the MavenProject of the current execution to make it available for the installation and deployment of the generated artifacts
• load-version: Read the stored information from the file deferring-maven-plugin.json and adjust artifact.version an artifact.versionRange of the current MavenProject to make it available for the installation and deployment of the generated artifacts.

Caution: Using the load-version goal may lead to situation where maven plugins being triggered after this goal are seeing another version than the version that is currently configured in the projects pom.xml. For releasing workflows this may nevertheless be intended.