Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
robinbanbury opened this issue Aug 13, 2020 · 11 comments · Fixed by #427
Closed

Comments

@robinbanbury
Copy link

robinbanbury commented Aug 13, 2020

The changes for 2.8.1 break the versions:set goal for any project that has a parent POM (e.g. a Bill of Materials POM) in a subdirectory.

Project directory structure:

+- pom.xml
+- product-bom
|   \- pom.xml
+- product-module1
|   \- pom.xml
|   \- src
|       \- ...
+- product-module2
|   \- pom.xml
|   +- src
|       \- ...
...

Extract from pom.xml:

  <parent>
    <groupId>org.test.product</groupId>
    <artifactId>product-bom</artifactId>
    <relativePath>product-bom/pom.xml</relativePath>
    <version>1.0.0-SNAPSHOT</version>
  </parent>

  <groupId>org.test.product</groupId>
  <artifactId>test-product</artifactId>
  <packaging>pom</packaging>

Extract from product-bom/pom.xml:

  <groupId>org.test.product</groupId>
  <artifactId>product-bom</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>pom</packaging>

Running mvn versions:set -DnewVersion=2.0.0-SNAPSHOT --file product-bom/pom.xml succeeds, but only updates the project version in product-bom/pom.xml - this breaks the project structure, as the test-product POM and product-bom POM version numbers no longer match.

Running mvn versions:set -DnewVersion=2.0.0-SNAPSHOT fails with the following message:

[ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.8.1:set (default-cli) on project test-product: Project version is inherited from parent. -> [Help 1]

Please could you revert this breaking change?

@khmarbaise
Copy link
Member

Do you have a full working example of this project?

@robinbanbury
Copy link
Author

I will assemble one that demonstrates the issue

@robinbanbury
Copy link
Author

https://github.com/robincsmith/versions-maven-plugin-2.8.1-breaking-change - includes a README, with replication steps

synox referenced this issue in apache/jackrabbit-oak Aug 13, 2020
josephlbarnett added a commit to trib3/leakycauldron that referenced this issue Aug 13, 2020
Latest version doesn't support setting version with
parent pom in a subdirectory, so use the last version
that worked.  Also better to specify version explicitly
than to automatically get latest version.

See mojohaus/versions#426
josephlbarnett added a commit to trib3/leakycauldron that referenced this issue Aug 13, 2020
Latest version doesn't support setting version with
parent pom in a subdirectory, so use the last version
that worked.  Also better to specify version explicitly
than to automatically get latest version.

See mojohaus/versions#426
@robinbanbury
Copy link
Author

@khmarbaise is this repo useful for reproducing the issue?

@stefanseifert
Copy link
Contributor

as discussed in #82 i propose to add a new property to the 'set' goal that optionally brings the previous behavior back. i'm the opinion that the new behavior is more correct and there are use cases which break if this change is reverted.

it would then be required to add this new property to the command like call like this (example, naming to be done):

mvn versions:set -DnewVersion=2.0.0-SNAPSHOT -DaggregationRoot=true --file product-bom/pom.xml

@robinbanbury
Copy link
Author

From an automation point of view, I don't think that's ideal. If our CI server is running the versions:set command using a custom POM file path, we can add this new flag to the Maven command line too. The issue is really in breaking backward compatibility. mvn versions:set -DnewVersion=... --file ... has worked for a long time, and could be embedded in a lot of build pipelines (i.e. not just ours); changing that behaviour requires any such build pipeline to be fixed.

Likewise, from a user point of view, it's potentially confusing to need to add this new flag to this handy, simple command that users will have run many times in the past.

I'd suggest adding a flag to enable the new feature. But I'm perhaps biased in that respect, as I'm using the old feature. Your suggestion may be the right one.

@sishbi
Copy link

sishbi commented Aug 19, 2020

I agree with @robincsmith. If you add a new flag it should be to switch on the new behaviour. Existing uses of the plugin should not be broken IMHO.

@stefanseifert
Copy link
Contributor

understood, if no other proposal is raised i can come up with a PR for this, adding an optional flag for the new behavior.

@sishbi
Copy link

sishbi commented Dec 15, 2020

Any progress update on this issue? I see the PR has been submitted - can you please tell me when will this be released?

@stefanseifert
Copy link
Contributor

i have no commit rights unfortuantely - maybe ask at the "MojoHaus Development" mailing list, see https://www.mojohaus.org/mail-lists.html

@digulla
Copy link

digulla commented Jan 15, 2021

I'lve stumbled over this as well. I think the stance of @ghilainm in #82 that he can organize his project tree in any way he wishes is wrong. Maven has very specific rules what it considers part of the reactor build. When I change the version of the parent POM of a reactor build, all related children (i.e. those POMs which use the modified POM as parent) should change as well.

If he puts different projects into one reactor build, then that's not really supported by Maven. It just works as long as he's careful.

I would prefer a flag which says "just change a single file". This should be possible by using -pl on the Maven command line. If -pl doesn't work, then add a -D flag to enable this. Then people like @ghilainm can add that in the configuration element in the POM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants