For years, I've been developing libraries as sets of modules sharing a
(semantic) version number. For each project, the project's root Maven
module defines the version number for all modules in the project. As a
result, intra-project dependencies can be efficiently declared like


My release process for version x.y.z of any project looks like this:

  $ git flow release start x.y.z
  $ mvn versions:set -DnewVersion=x.y.z
  $ git add pom.xml */pom.xml
  $ git commit -m 'Mark x.y.z'
  (try a build, wait for CI results, etc, etc, etc)
  $ git flow release finish
  $ git push --all
  $ git push --tags
  $ mvn clean deploy site site:stage && mvn nexus-staging:rc-list
  $ mvn nexus-staging:rc-close -DstagingRepositoryId=...
  $ mvn nexus-staging:rc-release -DstagingRepositoryId=...

However, I've recently begun migrating to OSGi and in an OSGi context,
as soon as you have API bundles, it makes more sense to have
independently semantically-versioned modules. The version number of the
aggregating root Maven module therefore identifies a set of module
versions as opposed to dictating a fixed version number for all

This is all fine, except for step 8 in my release process... If an API
module has not changed, the version number will not have changed.
Artifacts are immutable, and therefore I don't want to attempt to
deploy the same version of a module again. I can try to manually deploy
by specifying a list of projects with -pl, but this means that my
release process has to be different for each project. I have rather a
lot of projects (~70 and counting), so I'd prefer to avoid any
project-specific procedures in order to preserve my own sanity.

Is there some way I can get the deploy plugin (or possibly the nexus
staging plugin) to determine that it doesn't need to deploy a module


Attachment: pgp8r9qa_kzBF.pgp
Description: OpenPGP digital signature

Reply via email to