danielflower / multi-module-maven-release-plugin Goto Github PK

If I compare what I should supply to these two parameters, it seems that they need different content to point to the same thing..

forceRelease uses artifactId and modulesToRelease uses relative path within the repository.
And to make matters worse, the code that selects the projects to create tags for seems to only use the last part of the path. So if you have nested maven projects (not all of them are in the root directory) there will be no tags for the ones you release using modulesToRelease option. Skip the option and all tags will be created.

I'm willing to spend some time on making a patch for this, and I propose that the content for these two parameters are changed to use artifactId with an optional groupId, like this:

[groupId:]artifactId[, ...]

But, I'd like to have an ok from you before I start, so I do not do changes in one direction while you have plans in another for this.

Would the plugin work across more than one git repo ? I'm not talking about submodules, but rather several projects spread over as many repos, with one reactor project to build them all...

Guys -

This looks great!! Thanks for putting it together!

I'm having what I hope is a simple issue and thus continues my love-hate relationship with maven...

mvn -cpu releaser:help -Ddetail=true -Dgoal=release

... lots of stuff ellided...

[ERROR] No plugin found for prefix 'releaser' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/Users/quantum/.m2/repository), central (http://repo.maven.apache.org/maven2)] -> [Help 1]

... more stuff ellided...

I added the '-cpu' to try and force maven to search repos for plugins/dependencies.
It sure does LOOK like your stuff is out there... and I've been building for months with no trouble otherwise - no apparent changes other than your library and the rest of my project still builds properly.

I added the repositories and pluginRepositories sections only after I got the failure... the errors didn't change. Generally I find with Maven that I've done (or not done) something silly... Any thoughts?

Here's my pom for what it's worth:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.xyz.abc</groupId>
    <artifactId>webend</artifactId>
    <packaging>pom</packaging>
    <version>1.1</version>
    <name>Web and backend services</name>

    <modules>
        <module>common</module>
        <module>web</module>
        <module>backend</module>
    </modules>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>com.github.danielflower.mavenplugins</groupId>
                    <artifactId>multi-module-maven-release-plugin</artifactId>
                    <version>1.0.1</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <configuration>
                        <source>1.7</source>
                        <target>1.7</target>
                    </configuration>
                </plugin>

            </plugins>
        </pluginManagement>
    </build>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>


    <repositories>
        <repository>
            <id>central</id>
            <name>Maven Repository Switchboard</name>
            <layout>default</layout>
            <url>http://repo1.maven.org/maven2</url>
        </repository>
    </repositories>

    <pluginRepositories>
        <pluginRepository>
            <id>central</id>
            <name>Maven Plugin Repository</name>
            <url>http://repo1.maven.org/maven2</url>
        </pluginRepository>
    </pluginRepositories>

</project>

Thanks much!

Hi,

having some issues releasing 1.0.1 of my modules (i.e. only 1.0.0 has ever been released before).
During init I get this:

[ERROR] Failed to execute goal com.github.danielflower.mavenplugins:multi-module-maven-release-plugin:1.4.0:release (default-cli) on project fileservice: Error while looking up tag Ref[refs/tags/fileservice-1.0.0=eb81113cebac4c30c517a360e70194d284c8ca38]: Object eb81113cebac4c30c517a360e70194d284c8ca38 is not a tag. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.github.danielflower.mavenplugins:multi-module-maven-release-plugin:1.4.0:release (default-cli) on project fileservice: Error while looking up tag Ref[refs/tags/fileservice-1.0.0=eb81113cebac4c30c517a360e70194d284c8ca38]
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while looking up tag Ref[refs/tags/fileservice-1.0.0=eb81113cebac4c30c517a360e70194d284c8ca38]
    at com.github.danielflower.mavenplugins.release.AnnotatedTagFinder.tagsForVersion(AnnotatedTagFinder.java:30)
    at com.github.danielflower.mavenplugins.release.Reactor.fromProjects(Reactor.java:37)
    at com.github.danielflower.mavenplugins.release.ReleaseMojo.execute(ReleaseMojo.java:123)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 19 more
Caused by: org.eclipse.jgit.errors.IncorrectObjectTypeException: Object eb81113cebac4c30c517a360e70194d284c8ca38 is not a tag.
    at org.eclipse.jgit.revwalk.RevWalk.parseTag(RevWalk.java:815)
    at com.github.danielflower.mavenplugins.release.AnnotatedTag.fromRef(AnnotatedTag.java:44)
    at com.github.danielflower.mavenplugins.release.AnnotatedTagFinder.tagsForVersion(AnnotatedTagFinder.java:28)
    ... 23 more

The following tags exists:

$ 
git show-ref --tags
eb81113cebac4c30c517a360e70194d284c8ca38 refs/tags/fileservice-1.0.0
eb81113cebac4c30c517a360e70194d284c8ca38 refs/tags/fs-api-1.0.0
eb81113cebac4c30c517a360e70194d284c8ca38 refs/tags/fs-api-extra-1.0.0
eb81113cebac4c30c517a360e70194d284c8ca38 refs/tags/fs-client-1.0.0
eb81113cebac4c30c517a360e70194d284c8ca38 refs/tags/fs-server-1.0.0

fileservice is the root pom artifact, and the others are sub-modules.

Looking at the code, I cannot really see why this would happen.. AnnotatedTag.fromRef is called with tag which is directly derived from git.tagList().call();...

Tested with com.github.danielflower.mavenplugins:multi-module-maven-release-plugin:jar:1.4.0, and org.eclipse.jgit:org.eclipse.jgit:jar:3.7.1.201504261725 (also tested with jgit 4.0.2.201509141540-r, no success).

Any ideas?

Thanks for your work on this project Daniel.

I am finding that I cannot release when using an SSH connection to a private enterprise GitHub installation. Authentication from the command line git client is established using public/private ssh keys. At first I thought that the passphrase on the key was this issue. However I removed the passphrase and still encountered the stack trace listed below:

[INFO] --- multi-module-maven-release-plugin:1.0.2:release (default-cli) @ serenity-build ---
[ERROR] 
[ERROR] 
[ERROR] 
[ERROR] ************************************
[ERROR] Could not execute the release plugin
[ERROR] ************************************

...

Caused by: com.jcraft.jsch.JSchException: Auth fail
    at com.jcraft.jsch.Session.connect(Session.java:512)
    at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)

Do you have any suggestions on how username/password is set for this plugin?

Any thoughts on if or how we can add https authentication?

The transformed POM is written using platform encoding -- so for me, on Windows in Central Europe region, it is CP-1252. But the XML prolog remains <?xml version="1.0" encoding="UTF-8"?> making the POM unreadable.

Hi,
I had singe character changes in two lines of my protofile. The plugin ignored it and didnt release the version. Later when I reordered multiple lines, it did detect the change and released it. Btw this is in version 1.2.0.

If I have a pom with

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.example.lib</groupId>
                <artifactId>some-lib</artifactId>
                <version>1.0-SNAPSHOT</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

and then a child pom with

    <dependencies>
        <dependency>
            <groupId>com.example.lib</groupId>
            <artifactId>some-lib</artifactId>
        </dependency>
    </dependencies>

then the PomUpdater#alterModel will not work; dependency.getVersion() gives null and it is not regarded as a snapshot version.

Workaround was to just skip the dependency management, and rely on the plugin to update the inner version. However, need to remember to bump versions of all child packages when changing major/minor.

(In my case, the pom with depmanagement was not the root pom but a child pom, which in turn had one more child pom below. but don't think this makes a difference)

Hi.
At the moment, the build number is just a long and there is, for what I can see, no way to configure it differently in order to get something like <business-version>-<timestamp>-<commit-hash>.

There is already a delimiter property for separating the business version from "the rest", so what is missing is a way to specify such values.
The easiest way would be to make the buildNumber a String and it would then be up to the user to pass the value to use.

In this way - as side effect - would also be possible to remove the build number if it's not wanted (keeping the String null).

A possible strategy would be:

• if the buildNumber is specified:
  • if the string is not null and not empty, then attach the delimiter
  • try to parse it as Long and, if it works, just use parsed-value + 1
  • if the parsing fails, use the specified string
• else if no buildNumber is specified:
  • just use the business version alone

I am running
releaser:release
and have an error:
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- multi-module-maven-release-plugin:1.2.0:release (default-cli) @ ...
[ERROR]
[ERROR]
[ERROR]
[ERROR] ************************************
[ERROR] Could not execute the release plugin
[ERROR] ************************************
[ERROR]
[ERROR]
[ERROR] Cannot release with uncommitted changes. Please check the following files:
[ERROR] * .gitignore
[ERROR] * pom.xml
[ERROR] Please commit or revert these changes before releasing.
[ERROR]
git status shows all clean.
Some maven plugins allow to pass parameters to jgit like:
<jgit.ignore> pom.xml </jgit.ignore>
<jgit.dirtyWorkingTree>warning</jgit.dirtyWorkingTree>

how to do similar (or somehow configure jgit) with releaser plugin?

I'm using the 2.0.8 version of the plugin. Release build runs on a Bamboo agent. The error I get:

[ERROR] fatal: Could not switch to '/opt/git-2.7.4/etc/': No such file or directory

Full log in attachment.
plan-272991023-JOB1-3.txt

If I understand well, the plugin doesn't need the native git client to be installed on the agent. So I'm wondering why it tries to find the find the configuration in the directory mentioned above.

When executing the build from another directory than the project one using the -f parameter, the build fails:

[ERROR] ************************************
[ERROR] Could not execute the release plugin
[ERROR] ************************************
[ERROR] 
[ERROR] 
[ERROR] Releases can only be performed from Git repositories.
[ERROR] / is not a Git repository.

The plugin should take the -f parameter into account.

Hi

I believe there is a regression introduced since version 2.0.4.

We often use a property in the pom.xml scm tags, e.g.

<scm>
<developerConnection>scm:git:ssh://[email protected]/abc/${project.artifactId}.git</developerConnection>
</scm>

In 2.0.3 this worked fine, but since 2.0.4 the following exception is thrown (e.g. during releaser:next)

org.eclipse.jgit.api.errors.TransportException: ssh://[email protected]/abc/${project.artifactId}.git: GitLab: The project you were looking for could not be found.

It sounds as though the "${project.artifactId}" is now being sent directly to git, rather than the interpolated value.

This is a better statement of issue #49. I suggest closing that issue as a duplicate of this.
The plugin generates tags in the form artifactId-version. This forces artifact Ids to be unique.
Consider the following perfectly legal project structure:
-com.foo:parent
--com.foo:domain1
---com.foo.domain1:service
---com.foo.domain1:model
---com.foo.domain1:client
--com.foo:domain2
---com.foo.domain2:service
---com.foo.domain2:model
---com.foo.domain2:client

The release task fails because it attempts to generate duplicate tags. Consider using groupId-artifactId-version as the tag format. Or at least provide that as an option.

In the past I have deployed to Maven Central following https://central.sonatype.org/pages/ossrh-guide.html and specifically https://central.sonatype.org/pages/apache-maven.html

Basically my pom contains:

  <parent>
    <groupId>org.sonatype.oss</groupId>
    <artifactId>oss-parent</artifactId>
    <version>7</version>
  </parent>

and the release is performed using:

mvn release:prepare
mvn release:perform

I am just looking for confirmation that releaser:release is a drop-in/transparent replacement for this use case? Thanks!

I'd like to have an option for making pushes to remote repository optional. Since I am currently testing the transition, I have some test runs, which I would not be publishing, however, the tags for it would already go into github repo.

I've read your comment in #20 about handling failures, however with local tags I'm able to rollback just fine - I'll rollback the staging repo in Nexus, and remove the tags from my local repository.

I think that skipping versions in Maven Central, for which there would be a tag in project repository would be confusing for (the few) people using my libraries ;)

We have a multi module maven project that also contains a non-maven module for Vagrant configuration. It is therefore not mentioned in our parent / aggregator POM.

We noticed that making a change to that module causes the release build to release the whole project (all modules). It als happens for maven modules that are not referenced in the parent / aggregator POM.

I assume this isn't expected behaviour. Is their a property to prevent this from happening?

This kind of builds on top of #76. However, since it's likely a missing feature I report it separately.

Scenario

• multi-module project with 20+ modules
• in the root folder I keep a few "management" files alongside the root pom.xml like .editorconfig, .gitignore and .gitlab-ci.yml.

Problem: a single change to any of those files will trigger the release of each module upon next invocation of the plugin as the root project changed.

I argue that this is undesirable in most cases. (How) can this behavior be turned off?

When adding a new module to the project, the aggregator changes. This causes all the modules to be released in the project even though they have not changed.

We should:

1. Have more intelligent detection that can determine whether a change in the parent / aggregator POM has any impact on the release artifact. This option will probably be limited to modules only as it is quite difficult to know for sure whether there is an impact on referenced modules.
2. Have the option to set a flag to prevent releasing modules on parent / aggregator change.

Hi

I'm experiencing a problem when using the releaser plugin to release a pom project. If the pom has an active profile which contains property variables these are evaluated as part of the release and therefore hard-coded in the released version.

The following pom.xml demonstrates the problem I believe: https://gist.github.com/garyhodgson/f8a1cecd9d5819f89fc3cc2a41e71a8f

The following snippet is from the regular pom.xml:

$ cat "D:\Tools\Maven\.m2\repository\com\garyhodgson\example\mm-releaser-example\1.0-SNAPSHOT\mm-releaser-example-1.0-SNAPSHOT.pom"
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.garyhodgson.example</groupId>
    <artifactId>mm-releaser-example</artifactId>
    <version>1.0-SNAPSHOT</version>
    ...
      <profile>
            <id>format-source</id>
            ...
                    <directories>
                        <directory>${project.build.sourceDirectory}</directory>
                        <directory>${project.build.testSourceDirectory}</directory>
                        ...

The following from a released version:

$ cat "D:\Tools\Maven\.m2\repository\com\garyhodgson\example\mm-releaser-example\1.0.0\mm-releaser-example-1.0.0.pom"
<?xml version="1.0" encoding="UTF-8"?>
<project ...
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.garyhodgson.example</groupId>
  <artifactId>mm-releaser-example</artifactId>
  <version>1.0.0</version>
  ...
    <profile>
      <id>format-source</id>
     ...
                  <directories>
                    <directory>C:\Tools\Cygwin\tmp\mm-releaser-example\src\main\java</directory>
                    <directory>C:\Tools\Cygwin\tmp\mm-releaser-example\src\test\java</directory>
                    ...

The workaround is to turn off the profile when releasing this project, however this is error-prone as it can be forgotten, resulting in a released, incorrect pom.

I tried turning off the profile as part of the releaser plugin config (i.e. via !format-source) but this sadly did not work. The profile did not run, but the variables were still evaluated as part of the release. One can see how this might happen via the log message: "About to run mvn [deploy] with profiles [!format-source, format-source]"

Thanks for this plugin.

In the README there is this: "Figure out if things like MVN_OPTIONS and other JVM options need to be passed during release". Then answer from my perspective is yes!

Our unit tests require credentials be passed as system properties, which we normally do via MAVEN_OPTS in our Jenkins builds. I can't find a way to do this when the tests are started as part of a release via this plugin, so I had to disable tests when doing a release. And it would be nice to do that by doing -DskipTests=true, but that doesn't work either, so I did:

<plugin>
                <groupId>com.github.danielflower.mavenplugins</groupId>
                <artifactId>multi-module-maven-release-plugin</artifactId>
                <version>1.4.0</version>
                <configuration>
                    <releaseGoals>
                        <releaseGoal>deploy</releaseGoal>
                    </releaseGoals>
                    <skipTests>true</skipTests>
                </configuration>
</plugin>

This works OK but it would be nice to pass these options in the normal way, on the command line or MAVEN_OPTS. Thanks!

A git comment prefix will allow the build tools to ignore a particular commit created by release plugin. Else this will endlessly create versions as each release on master will commit and cycle back to release process.

To skip this only thing required is git commit prefix. http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#scmCommentPrefix

When Maven modules are in separate repositories release plugin does not work.

Hey this plugin looks awesome, but I can't get it working because I always get the following error:
Authentication is required but no CredentialsProvider has been registered

I guess I need to configure the credentials for JGIT to work. But I can't seem to find how to do this.
I find some info on programmatically configuring JGIT, but never in a Maven context.

I'm suspecting this is a dumb question, but however can't seem to find the answer...
Any tips?

Considering a multi-module project that defines 2modules (A, B), the B is a multi-module itself (with Bx, By & Bz as sub-modules)
And the 'multi-module-maven-release-plugin' is declared in the parent pom & in the pom of B module as well
What we can expect during a release after just a change in the sub-module Bx, is a release of the whole module B with the same version & a single tag !
Which is not the behavior of the releaser plugin, as it releases just Bx module so now it has a higher version of it's parent module B!

The idea is to have the hability to define the scope of something releasable (whether it is a simple project or a multi-module project)

Jenkins Config File Provider Plugin passes selected maven settings to the release mojo from a temporary created settings file (e.g. -s /tmp/settings4492055473509834167.xml). These settings are set on release but not passed to releaser's goals.

There are few things I don't understand about this plugin which I find no answers for in the documentation.

• I assume the plugin invokes the Maven deploy phase & plugin at the end of the release process just like the traditional plugin does?
• The SSH & HTTPS authentication configurations are explained quite nicely at http://danielflower.github.io/multi-module-maven-release-plugin/usage.html#Authentication. However, AFAICS it doesn't say anywhere if the configuration is for authenticating against the Git repository or against the deployment endpoint (e.g. Nexus). What if these two remote locations need different authentication schemes?
• How does the plugin determine if it should release not? Put differently for which events will it create a new release?
• How does the plugin determine the next build number? What information sources does it analyze e.g. Git local & remote tags, Maven locale & repo content, others?
• There is this message " [WARNING] No changes have been detected in any modules so will re-release them all" that's a bit irritating as it seems to contradict one of the fundamental propositions of the plugin which is

only those modules that have changes should be released

Hello,
I've created a profile with the enforcer plugin in order to ensure that some properties are being called before the release begin.
I've added that profile to the releaseProfile property and it is being activated, BUT ONLY after the release plugin have created the TAGs.
If the properties was not provided I have to remove the tags by hand...

        <plugin>
           <groupId>com.github.danielflower.mavenplugins</groupId>
           <artifactId>multi-module-maven-release-plugin</artifactId>
           <version>3.0.0</version>
           <configuration>
               <releaseProfiles>
                   <releaseProfile>when-releasing-ensure-requirements</releaseProfile>
               </releaseProfiles>
           </configuration>
       </plugin>

    <profile>
      <!-- THIS PROFILE WILL BE CALLED BY THE RELEASER:RELEASE -->
      <!-- It will ensure that the required properties are being provided -->
       <id>when-releasing-ensure-requirements</id>
       <activation>
           <activeByDefault>false</activeByDefault>
       </activation>
       <build>
           <plugins>
               <plugin>
                   <groupId>org.apache.maven.plugins</groupId>
                   <artifactId>maven-enforcer-plugin</artifactId>
                   <inherited>true</inherited>
                   <configuration>
                       <failFast>true</failFast>
                       <fail>true</fail>
                       <ignoreCache>true</ignoreCache>
                   </configuration>
                   <executions>
                       <execution>
                           <id>enforce-property</id>
                           <goals>
                               <goal>enforce</goal>
                           </goals>
                           <phase>validate</phase>
                           <configuration>
                               <rules>
                                   <requireProperty>
                                      <property>c8tech.build.release</property>
                                       <message>You must set the
                                           release property, so all
                                          profiles related are
                                           called.
                                       </message>
                                   </requireProperty>
                               </rules>
                           </configuration>
                       </execution>
                   </executions>
               </plugin>
           </plugins>
       </build>
   </profile>

I am trying to use your multi-module-maven-release-plugin Version 1.4.6 or 2.0.3 for the very first time. But i cant get it to work. The releaser:release goal throws the following error. Any Idea?

releasererror.txt

When passing the buildNumber from cli as the commit count, we may want neither to push tag to a remote repository nor to tag locally, just do edit -> deploy -> revert finally.

So, we need a boolean configuration to disable tag locally, such as 'localTag', default value is true.

Great plugin. However, the release task removes comments in the pom file. It also does not preserve the formatting. This is irritating and, it would seem, unnecessary when only version numbers need to be replaced.

It seems that with maven 3.3.x the plugin doesn't work because the MavenInvoker expects mvn.bat to exist, but that's been renamed to mvn.cmd. More details at https://issues.apache.org/jira/browse/MSHARED-413

Should be able to fix by upgrading the maven invoker version.

I tried to release a multi module project and it failed.
one of the modules being release was using a dependency that was only installed in the local repository. As the release plugin was not able to find it in the remote repository it fail the release, but all modules already released was kept...

it was a mess to turn back all modules in same version again... and then try to release again

Our business versions have 3 parts, e.g. 1.2.3. We append the build numbers as 4th digit, but for maven to be able to order the releases, this has to be separated with a dash ([How Version Numbers Work in Maven]
(https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#A1000661))

The plugin should apply the versioning schema of maven correctly, e.g. when there is a business version 1.2.3, the plugin should use 1.2.3-0 as verision, not 1.2.3.0

Hi,

I got a project with common libraries, each library within a submodule. They are different enough to warrant individual releases, thus this plugin seems perfect.
I would like to have a BOM file with the "latest" version of all libraries, which the end-user projects can import via dependency management. It seems messy to update this manually for every release though.

Basically, I wan't end-user projects within the organization to automatically benefit from any minor patches the libraries get, without having to go through every project and bump the version number whenever a lib version changes.

Something like [1.0.0,2.0.0) and strict semantic versions could be an alternative approach.

Have you had any similar situations, and how do you solve them?

Hello!
I get an error if I execute the command "mvn releaser:release". In our company we are using bitbucket for all our git repositories and private/public keys for authentication. Here is the stacktrace. Any ideas what could be wrong?

[ERROR] ssh://git@***/multi-module-test.git: USERAUTH fail [ERROR] Stack trace: [ERROR] org.eclipse.jgit.api.errors.TransportException: ssh://git@***/multi-module-test.git: USERAUTH fail at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:221) at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:159) at com.github.danielflower.mavenplugins.release.LocalGitRepo.allRemoteTags(LocalGitRepo.java:186) at com.github.danielflower.mavenplugins.release.Reactor.getRemoteBuildNumbers(Reactor.java:115) at com.github.danielflower.mavenplugins.release.Reactor.fromProjects(Reactor.java:47) at com.github.danielflower.mavenplugins.release.ReleaseMojo.execute(ReleaseMojo.java:113) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.eclipse.jgit.errors.TransportException: ssh://git@***/multi-module-test.git: USERAUTH fail at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:160) at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:137) at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:264) at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:162) at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:198) ... 27 more Caused by: com.jcraft.jsch.JSchException: USERAUTH fail at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:119) at com.jcraft.jsch.Session.connect(Session.java:463) at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:117) ... 31 more

Did a release today, and noticed the parent module was re-released. There only change to this was that .gitignore had been updated.

It would be useful if files known to not affect the release could be marked ignored. .gitignore would be such a file.

Similar to forceRelease option, a skipRelease option should exist for not releasing a module even when changes are detected. My use case is following:

My repo is bunch of loosely related libraries and over time we're adding more. When I add a new module, I want to release just the parent and the new module (or even just the new module, skipping the parent). Without this option, the plugin would release all modules, because they depend on the parent, even though nothing changed in their dependencies or source code.

I've made changes to my "root" pom.xml, and to a number of child modules (both pom and src).
The child changes are picked up fine, but the root pom change is not:

$ git diff lib-parent-1.0.1..HEAD pom.xml
diff --git a/pom.xml b/pom.xml
index 253c3a6..0592524 100644
--- a/pom.xml
+++ b/pom.xml
@@ -33,7 +33,7 @@
                <grizzly2.version>2.3.19</grizzly2.version>

                <!-- Newer than Jerseys -->
-               <jackson.version>2.5.1</jackson.version>
+               <jackson.version>2.6.1</jackson.version>

@@ -54,6 +54,7 @@
                <module>test-utils</module>
                <module>...</module>
                <module>...</module>
+               <module>utils</module>
        </modules>

        <dependencyManagement>

utils is a new module which did not exist before.

During releaser:release:

[INFO] Will use version 1.0.1 for lib-parent as it has not been changed since that release.
[INFO] Will use version 1.0.2 for test-utils as it has not been changed since that release.
...
[INFO] Will use version 1.0.0 for utils as it has changed since the last release.
...

The root project only has a pom.xml, no sources.

UPDATE: The problem was caused because 2 modules had the same artifactId. Consider changing the tag format from artifactId-version to groupId-artifactId-version.

#This plugin looks great. I confirmed it works on a small project, then tried a larger project. The structure is:
-parent
--entity
---common
---order
--repository
--service
----empdaemon
----order
--util
Initially, all versions are 1.0-SNAPSHOT, I committed and pushed the changes. Then I tried to release. The output is shown below. I am at a loss as to how to proceed. Any help would be appreciated.
$ mvn releaser:release
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] parent
[INFO] entity
[INFO] common
[INFO] order
[INFO] util
[INFO] repository
[INFO] service
[INFO] empdaemon
[INFO] order
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building parent 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- multi-module-maven-release-plugin:2.1.2:release (default-cli) @ parent ---
[INFO] Will use version 1.0.0 for parent as it has changed since the last release.
[INFO] Releasing entity 1.0.0 as parent has changed.
[INFO] Releasing common 1.0.0 as entity has changed.
[INFO] Releasing order 1.0.0 as entity has changed.
[INFO] Releasing util 1.0.0 as parent has changed.
[INFO] Releasing repository 1.0.0 as parent has changed.
[INFO] Releasing service 1.0.0 as parent has changed.
[INFO] Releasing empdaemon 1.0.0 as util has changed.
[INFO] Releasing order 1.0.0 as order has changed.
[INFO] Going to release parent 1.0.0
[INFO] Going to release entity 1.0.0
[INFO] Going to release common 1.0.0
[INFO] Going to release order 1.0.0
[INFO] Going to release util 1.0.0
[INFO] Going to release repository 1.0.0
[INFO] Going to release service 1.0.0
[INFO] Going to release empdaemon 1.0.0
[INFO] Going to release order 1.0.0
[INFO] About to tag the repository with parent-1.0.0
[INFO] About to tag the repository with entity-1.0.0
[INFO] About to tag the repository with common-1.0.0
[INFO] About to tag the repository with order-1.0.0
[INFO] About to tag the repository with util-1.0.0
[INFO] About to tag the repository with repository-1.0.0
[INFO] About to tag the repository with service-1.0.0
[INFO] About to tag the repository with empdaemon-1.0.0
[INFO] About to tag the repository with order-1.0.0
[ERROR]
[ERROR]
[ERROR]
[ERROR] ************************************
[ERROR] Could not execute the release plugin
[ERROR] ************************************
[ERROR]
[ERROR]
[ERROR] There was an error while accessing the Git repository. The error returned from git was:
[ERROR] tag 'Tag={
object 2e7d3636dd683f1e88f95d85e98d51f19b9daa81
type commit
tag order-1.0.0
tagger PersonIdent[parker.douglass, [email protected], Thu Mar 23 16:57:49 2017 -0600]

{"version":"1.0","buildNumber":"0"}}' already exists
[ERROR] Stack trace:
[ERROR] org.eclipse.jgit.api.errors.RefAlreadyExistsException: tag 'Tag={
object 2e7d3636dd683f1e88f95d85e98d51f19b9daa81
type commit
tag order-1.0.0
tagger PersonIdent[parker.douglass, [email protected], Thu Mar 23 16:57:49 2017 -0600]

{"version":"1.0","buildNumber":"0"}}' already exists
at org.eclipse.jgit.api.TagCommand.updateTagRef(TagCommand.java:193)
at org.eclipse.jgit.api.TagCommand.call(TagCommand.java:164)
at com.github.danielflower.mavenplugins.release.AnnotatedTag.saveAtHEAD(AnnotatedTag.java:76)
at com.github.danielflower.mavenplugins.release.LocalGitRepo.tagRepo(LocalGitRepo.java:113)
at com.github.danielflower.mavenplugins.release.LocalGitRepo.tagRepoAndPush(LocalGitRepo.java:100)
at com.github.danielflower.mavenplugins.release.ReleaseMojo.tagAndPushRepo(ReleaseMojo.java:174)
at com.github.danielflower.mavenplugins.release.ReleaseMojo.execute(ReleaseMojo.java:125)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.
java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

[ERROR]
[ERROR]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] parent ............................................. FAILURE [ 12.558 s]
[INFO] entity ............................................. SKIPPED
[INFO] common ............................................. SKIPPED
[INFO] order .............................................. SKIPPED
[INFO] util ............................................... SKIPPED
[INFO] repository ......................................... SKIPPED
[INFO] service ............................................ SKIPPED
[INFO] empdaemon .......................................... SKIPPED
[INFO] order .............................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.985 s
[INFO] Finished at: 2017-03-23T16:57:49-06:00
[INFO] Final Memory: 35M/346M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.danielflower.mavenplugins:multi-module-maven-release-plugin:2.1.2:release (def
ault-cli) on project parent: Could not release due to a Git error -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

OS: RHEL 7.3

I don't seem to have a 'netcat' application at all, however I do have a 'ncat' that does have a -U option. As far as I can tell, it is the same application.

Could the application try both?

[WARNING] Failed to connect to SSH-agent
com.jcraft.jsch.agentproxy.AgentProxyException: netcat does not support -U option.
	at com.jcraft.jsch.agentproxy.usocket.NCUSocketFactory.<init>(NCUSocketFactory.java:70)
	at com.github.danielflower.mavenplugins.release.SshAgentSessionFactory.createDefaultJSch(SshAgentSessionFactory.java:80)
	at org.eclipse.jgit.transport.JschConfigSessionFactory.getJSch(JschConfigSessionFactory.java:261)
	at org.eclipse.jgit.transport.JschConfigSessionFactory.createSession(JschConfigSessionFactory.java:220)
	at org.eclipse.jgit.transport.JschConfigSessionFactory.createSession(JschConfigSessionFactory.java:176)
	at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:110)
	at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:137)
	at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:264)
	at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:162)
	at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:198)
	at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:159)
	at com.github.danielflower.mavenplugins.release.LocalGitRepo.allRemoteTags(LocalGitRepo.java:186)
	at com.github.danielflower.mavenplugins.release.Reactor.getRemoteBuildNumbers(Reactor.java:120)
	at com.github.danielflower.mavenplugins.release.Reactor.fromProjects(Reactor.java:46)
	at com.github.danielflower.mavenplugins.release.NextMojo.execute(NextMojo.java:37)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

When building from an otherwise clean checkout, the plugin complains that my submodule has Uncommited changes.
Happens both when submodule is NOT inited/checked out (which is good), but also when it is checked out and untouched/up to date.

git clone, push worked with same private key that i am putting in "${project.basedir}/id_rsa". I notice that the error "GitLab: The project you were looking for could not be found" appears when I disable the public key in gitlab. So, it is possible that plugin is defaulting to ~/id_rsa and ignoring what i am putting in pom?
Daniel Flower Mod Durgesh Verma • 4 days ago
Yes, that sounds like the problem. That's not supported currently sorry but feel free to open an issue on the GitHub page or make a pull request.

This is an awesome project!

I use SSH authentication for connecting to an AWS CodeCommit repo. This involves referring to "codecommit credential-helper" in my ~/.gitconfig file. I'm not sure exactly what happens in the background...

It seems like your plugin can only get its credentials through the maven settings file, so I think I'm locked out for now. Any idea how hard this would be to solve? Thanks!

John

We have a multi module project where 1 module contains Checkstyle configuration. That modules is then included in the parent POM as a plugin dependency:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>2.16</version>
    <dependencies>
        <dependency>
            <groupId>com.my.company</groupId>
            <artifactId>my-artifact</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
</plugin>

When releasing, the build fails stating that it cannot resolve the dependency. This because the release plugin does not rewrite the plugin dependency.

Currently we need to set it to a release version, but every time we release a new version we need to update the parent. And that then causes a release of all child modules again...

Can the plugin be updated to take into account plugin dependencies?

I'm trying to migrate soundlibs, and the trying to run releaser:next fails with:

[ERROR] Failed to execute goal com.github.danielflower.mavenplugins:multi-module-maven-release-plugin:2.0.3:next (default-cli) on project soundlibs:

Caused by: org.apache.maven.plugin.MojoExecutionException: Error while looking up tag Ref[refs/tags/soundlibs-1.2=41001253ddbbc429b2de4dbc2efb1a1d93c75806]
        at com.github.danielflower.mavenplugins.release.AnnotatedTagFinder.tagsForVersion(AnnotatedTagFinder.java:30)
        at com.github.danielflower.mavenplugins.release.Reactor.fromProjects(Reactor.java:37)
        at com.github.danielflower.mavenplugins.release.NextMojo.execute(NextMojo.java:39)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
        ... 20 more
Caused by: org.eclipse.jgit.errors.IncorrectObjectTypeException: Object 41001253ddbbc429b2de4dbc2efb1a1d93c75806 is not a tag.
        at org.eclipse.jgit.revwalk.RevWalk.parseTag(RevWalk.java:834)
        at com.github.danielflower.mavenplugins.release.AnnotatedTag.fromRef(AnnotatedTag.java:44)
        at com.github.danielflower.mavenplugins.release.AnnotatedTagFinder.tagsForVersion(AnnotatedTagFinder.java:28)
        ... 24 more

First idea was to just unpack refs, into refs/tags, but that wasn't enough.

This is a great plugin, thanks a lot!

Are there any plans to support git submodules already? I have just tried it with a reactor pom and two submodules. The releasing itself worked well in some sense: New versions of my (sub-)modules were uploaded to the repository.

However, I ran into two problems

• A (sub-)module was released even though there was no change since the last release
• The revert to the original pom.xml contents could not be performed

How could we contribute to such an extension? Are there are any efforts already started? Do you see any impediments regarding this requirement?

I have the following requirement: Enable snapshots when they can be resolved to a concrete version. In particular I would like to release a module A which is not directly related to a module B in terms of a common multi module build. Then B should be releasable while still maintaining a certain snapshot dependency to A. This would make the life of developers easier, since they could still work locally with snapshot versions of A and B. At the same time we could provide a central CI/CD build of A and B with subsequent versions of the two modules resolved to a concrete version of A when B is released.

Example: A is having version 1.3-SNAPSHOT, B depends on that very version. A is released as 1.3.0, 1.3.1, 1.3.2 etc. When B is released the snapshot dependency to A can be resolved to - for instance - version 1.3.3 (or whatever is the latest version in the moment(s) B is released).

Background: I was trying to build a continuous delivery pipeline with Maven based on the nice MMMR-Plugin. Therefore I already introduced an extension to enable this feature based on MMMR-Plugin version 1.4.4. We have successfully used the extension for some time now in our OSS project "DukeCon" (cf. https://dev.dukecon.org/jenkins/view/Build%20Pipeline%20Develop/job/dukecon_server_develop_releaser).

A merge with the latest MMMR-Plugin (2.0.4) is already under way (will raise a pull request soon).