You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by or...@io7m.com on 2017/02/05 13:38:24 UTC
Deploying independently versioned modules
Hello.
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
this:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>a-module</artifactId>
<version>${project.version}</version>
</dependency>
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
submodules.
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
twice?
M
Re: Deploying independently versioned modules
Posted by or...@io7m.com.
On 2017-02-08T19:25:01 -0800
Charles Honton <ch...@honton.org> wrote:
> Take a look at maven exists plugin [https://chonton.github.io/exists-maven-plugin/0.0.2/ <https://chonton.github.io/exists-maven-plugin/0.0.2/>]. This has goals to prevent deployment or installation of artifacts which already exist.
>
Ah, interesting, thank you!
I'll be testing this one today.
M
Re: Deploying independently versioned modules
Posted by Charles Honton <ch...@honton.org>.
Take a look at maven exists plugin [https://chonton.github.io/exists-maven-plugin/0.0.2/ <https://chonton.github.io/exists-maven-plugin/0.0.2/>]. This has goals to prevent deployment or installation of artifacts which already exist.
> On Feb 5, 2017, at 5:38 AM, org.apache.maven.user@io7m.com wrote:
>
> Hello.
>
> 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
> this:
>
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>a-module</artifactId>
> <version>${project.version}</version>
> </dependency>
>
> 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
> submodules.
>
> 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
> twice?
>
> M