[Bug 2.3] Local aggregation root is searched to set the version

[ghilainm]

I think this peace of code from the SetMojo.java is not correct.
final MavenProject project = PomHelper.getLocalRoot( projectBuilder, getProject(), localRepository, null, getLog() ); getLog().info( "Local aggregation root: " + project.getBasedir() );

I end with my all project modified despite I only wanted to change a one maven module. It automatically searches for the local aggregator root which I think it should not.

[fabiojb]

I think that the local agregator is not used directly to define what projects will change.

If you want to change the version of one project only, make the maven call from that project. If the version is inherited from a parent pom, you can make the maven call from the parent pom and use the -pl <name of the child module> to change only the version of that specific project.

[ghilainm]

I do think it is used because I changed that piece of code to getProject and only the local pom and all the other modules it defined are changed. You cannot assume automatically that I want to change the whole hierarchy of my maven project everybody is free to organise it as it wishes and my pom versions are evolving independently. So I think it is a bug. Because I have no easy way to get around this behaviour.

[dweomer]

This is also problematic for me. I have a fork of two-module project living under a parent in the repository. Both modules inherit from the Spring Boot parent and NOT the reactor that is aggregating them. When trying to versions:set when in a module directory I see:

[INFO] --- versions-maven-plugin:2.3:set (example) @ server ---
[INFO] Searching for local aggregator root...
[INFO] Local aggregation root: /Users/jlebc/Projects/example
[INFO] Processing change of example:server:0.0.1-SNAPSHOT -> 0.1.0-SNAPSHOT
[ERROR] 
java.io.FileNotFoundException: /Users/jlebc/Projects/example/server/server (No such file or directory)
        at java.io.FileInputStream.open0(Native Method)
        at java.io.FileInputStream.open(FileInputStream.java:195)
        at java.io.FileInputStream.<init>(FileInputStream.java:138)
        at org.codehaus.plexus.util.xml.XmlReader.<init>(XmlReader.java:124)
        at org.codehaus.plexus.util.xml.XmlStreamReader.<init>(XmlStreamReader.java:67)
        at org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:118)
        at org.codehaus.mojo.versions.api.PomHelper.readXmlFile(PomHelper.java:1606)
        at org.codehaus.mojo.versions.AbstractVersionsUpdaterMojo.process(AbstractVersionsUpdaterMojo.java:321)
        at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:298)
        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)

And this is invoked from /Users/jlebc/Projects/example/server. Notice the duplicated module directory.

[travisspencer]

I think I am running into the same problem as @dweomer. Has anyone found a workaround for this?

[dweomer]

I should also note that I see the exact same failure when invoking from the parent directing but specify the module via the -pl / --projects switch.

[khmarbaise]

Does someone has an example project for that?

[sergei-ivanov]

@khmarbaise, please find a sample project attached:
issue82.zip

[stefanseifert]

i run into this problem as well when using gitflow-maven-plugin which uses versions-maven-plugin internally to update the versions in the released artifacts.

due to this bug other versions in the same git repository but outside the directory/module structure that is released are (automatically) modified as well and are part of the release commits.

in PR #400 i've added an IT for the problem and a fix - i've just removed the lookup of parent POMs to do the change - it makes no sense in my POV and none of the other ITs relayed on it.

[sirianni]

I haven't fully gone through all the details above, but our project is now broken upon upgrading to v2.8.1 that contains the fix #400

We have a setup:

/project-root/pom.xml
    /parent-pom/pom.xml
    /module-1/pom.xml
    /module-2/pom.xml

Where module-1 and module-2 inherit from parent-pom.

On v2.7 running mvn versions:set --projects parent-pom -DnewVersion=x.y.z bumps the version in parent-pom/pom.xml and also in the <parent> element of module-1/pom.xml and module-2/pom.xml.

On v2.8.1 the same command only bumps the version in parent-pom/pom.xml.

[stefanseifert]

@sirianni you're right - this is no longer working. in my pov the new behavior is correct - with the --projects command you define maven to execute on the child module "parent-pom", and it operates also on siblings of it.

but of course it see that your use case makes sense. did you check if any of the other goals can be used instead?
https://www.mojohaus.org/versions-maven-plugin/

alternatively we might think about adding a new switch to this goal that restored the previous behavior, but only if explicitly wanted as it can lead to unexpected results in other scenarios (that's why this bug exists).

[sishbi]

I think this change should be reverted as it breaks for my use-case. I have checked the other goals and none of them seem to work, I tried the update-parent goal but all it says is 'Project's parent is part of reactor' or 'Project version is inherited from parent' and no changes are made to the pom.xml
For now I have reverted back to v2.7.
This issue is tracked in #426

[stefanseifert]

see my comment in #426 (comment) - would this help for you?