Test case for module hierarchy

[piotrgwiazda]

Test case for issue #14 - handling pom hierarchy inside multi-module Maven project

[jan-molak]

Brilliant, thanks!

So if I understand correctly, the hierarchy you have in mind looks like this:

├── pom.xml          // grand-parent
├── project-parent
│   └── pom.xml      // parent
└── project-child
    └── pom.xml      // child

It looks like in the test case you provided the grand-parent defines two modules: parent and child, while the parent defines no modules.

Under what circumstances would you use this hirarchy as opposed to one where:

• grand-parent specifies one module: parent
• parent specifies one module child

Thanks, Jan

[piotrgwiazda]

It's a common pattern when you separate module build aggregation from inheritance.

https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation 16 wrz 2016 17:14 "Jan Molak" notifications@github.com napisał(a):

Brilliant, thanks!

So if I understand correctly, the hierarchy you have in mind looks like this:

├── pom.xml // grand-parent ├── project-parent │ └── pom.xml // parent └── project-child └── pom.xml // child

It looks like in the test case you provided the grand-parent defines two modules: parent and child, while the parent defines no modules.

Under what circumstances would you use this hirarchy as opposed to one where:

• grand-parent specifies one module: parent
• parent specifies one module child

Thanks, Jan

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/smartcodeltd/release-candidate-maven-plugin/pull/15#issuecomment-247627018, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFbl25WI55rTmcksjZXRfzI1ujwQpLTks5qqrJOgaJpZM4J7Xh5 .

[jan-molak]

Cool, thanks, makes sense. The problem was caused by Release Candidate trying to provide support for overriding release-style version numbers (see #8).

Having thought about it more, I'm now of an opinion that the plugin shouldn't touch anything that's not a SNAPSHOT; Also, introducing this restriction helps to determine which pom in the parent pom chain is a "project parent" (most likely defined as SNAPSHOT) and which one is an "organisation parent" (most likely to have a release version).

Please feel free to propose changes in the implementation via a PR if the above reasoning could be improved.

J

[piotrgwiazda]

Looks good. Thanks! I would not expect organization pom sitting inside ssme multi module project but to be pulled in from repo. 17 wrz 2016 19:20 "Jan Molak" notifications@github.com napisał(a):

Cool, thanks, makes sense. The problem was caused by Release Candidate trying to provide support for overriding release-style version numbers (see

8

https://github.com/smartcodeltd/release-candidate-maven-plugin/issues/8 ).

Having thought about it more, I'm now of an opinion that the plugin shouldn't touch anything that's not a SNAPSHOT; Also, introducing this restriction helps to determine which pom in the parent pom chain is a "project parent" (most likely defined as SNAPSHOT) and which one is an "organisation parent" (most likely to have a release version).

Please feel free to propose changes in the implementation via a PR if the above reasoning could be improved.

J

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/smartcodeltd/release-candidate-maven-plugin/pull/15#issuecomment-247791193, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFbl6DPbSwwwyTADjiGDxPIAJgtRCSGks5qrCFtgaJpZM4J7Xh5 .

[jan-molak]

No, me neither :-) Good stuff, glad that it helped!

J