Questions regarding suitability for a use case

[nmatt]

Hi,

I'm trying to assess whether this plugin would be suitable for our use case, and hope that you can help me clarifying that. We have a large mult-module project (many dozens of submodules with interdependencies) and have two modes of release:

1. major releases where all modules are released with a common version number x.y.0
2. patch releases where some subset of modules (that have changed) are newly released with a version x.y.z with z > 0

Major releases can be handled with the Maven Release plugin. Patch releases however are difficult, and maybe this plugin would be suitable for those.

Some important details:

• Consecutive patch releases (based on the same major release) should use the same patch version (z component) for all modules that changed in that patch release. For example, if in patch release 1 modules A and B changed (and are thus released with version x.y.1), and then in patch release 2 modules B and C have changed, then both modules B and C should be released as versions x.y.2. In particular, module C would have version x.y.2 although there was no version x.y.1 of it. (The purpose is to be able to easily identify which module last changed in which patch release.)
• Some modules have multiple levels of parent POMs within the multi-module project. The module versions are however all managed in the dependencyManagement section of the common root parent POM. Meaning that when a module version is updated, it also needs to be updated in that root pom. The Maven Release plugin does this; I assume this plugin does as well?
• The release process should be able to validate and test the complete multi-module project (i.e. the equivalent of mvn clean test on the top-level project), to ensure that the modules are all compatible with each other before release.
• There are modules that package their dependencies (e.g. WAR modules). This means that when any of its dependencies have changed (including transitive dependencies), then such a module needs to be newly released as well, so that the new versions of its dependencies are packaged into the resulting artifact.

Are the above possible using this plugin?

In addition, the following are unclear to me:

• How exactly does the plugin determine that a module has changed? The Usage page seems to be saying that the change determination is based on the previous release artifacts. This issue comment, on the other hand, seems to be saying that the comparison is based on Git commits. How exactly does it work?
• Under Running a partial release, the Usage page states that "If MyApp depends on another module, than that module will also be built and released". I don't understand this. Why would its dependencies also be re-released (other than those that have changed)?

[danielflower]

Hello, I think the plugin does some but not all of what you want and probably depends on specific details of your build.

So I suggest you just try it. You can set the release goals to something that won’t deploy to nexus or whatever - just run compile instead of the default deploy for example - and either set push tags to false or point it at a fork you don’t care about having tags added to, and just experiment like that.