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

ghilainm · 2016-06-06T13:29:13Z

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.

The text was updated successfully, but these errors were encountered:

fabiojb · 2016-06-27T16:42:16Z

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 · 2016-06-28T21:20:25Z

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 · 2017-04-12T23:55:52Z

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 · 2017-05-03T07:17:48Z

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

dweomer · 2017-05-05T16:34:45Z

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 · 2017-05-27T14:21:00Z

Does someone has an example project for that?

sergei-ivanov · 2018-03-02T11:53:51Z

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

stefanseifert · 2020-05-20T16:31:49Z

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.

…ld directories), not the parent or sibling directories

sirianni · 2020-08-13T17:53:50Z

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 · 2020-08-13T20:05:47Z

@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 · 2020-08-19T11:24:19Z

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 · 2020-08-19T11:46:10Z

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

…s of the local aggregation root that was present before the fix for #82 introduce a new flag processFromLocalAggregationRoot that enables the new (and probably more correct) behavior by setting it it false ensure old and new behavior are covered by integration tests

stefanseifert mentioned this issue May 20, 2020

Fixes #82 ensure version change affects only the current directory (and child directories), not the parent or sibling directories #400

Merged

khmarbaise closed this as completed in #400 May 21, 2020

khmarbaise pushed a commit that referenced this issue May 21, 2020

#82 ensure version change affects only the current directory (and chi…

783f9ce

…ld directories), not the parent or sibling directories

stefanseifert mentioned this issue Aug 19, 2020

2.8.x: Unable to set project version when parent POM is in a project subdirectory #426

Closed

stefanseifert mentioned this issue Sep 1, 2021

Fixes #426 restore default behavior on setting versions in all modules of the local aggregation root that was present before the fix for #82 #427

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

ghilainm commented Jun 6, 2016 •

edited

fabiojb commented Jun 27, 2016 •

edited

ghilainm commented Jun 28, 2016

dweomer commented Apr 12, 2017

travisspencer commented May 3, 2017

dweomer commented May 5, 2017

khmarbaise commented May 27, 2017

sergei-ivanov commented Mar 2, 2018

stefanseifert commented May 20, 2020

sirianni commented Aug 13, 2020

stefanseifert commented Aug 13, 2020

sishbi commented Aug 19, 2020

stefanseifert commented Aug 19, 2020

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

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

Comments

ghilainm commented Jun 6, 2016 • edited

fabiojb commented Jun 27, 2016 • edited

ghilainm commented Jun 28, 2016

dweomer commented Apr 12, 2017

travisspencer commented May 3, 2017

dweomer commented May 5, 2017

khmarbaise commented May 27, 2017

sergei-ivanov commented Mar 2, 2018

stefanseifert commented May 20, 2020

sirianni commented Aug 13, 2020

stefanseifert commented Aug 13, 2020

sishbi commented Aug 19, 2020

stefanseifert commented Aug 19, 2020

ghilainm commented Jun 6, 2016 •

edited

fabiojb commented Jun 27, 2016 •

edited