includeOnlyReactor: Update versions of only internal dependencies reachable from root in multi-module/reactor build about versions HOT 6 CLOSED

Ok..misunderstanding on my site..

from versions.

I also need such a feature. Please consider implementing it.
Thanks!

from versions.

What about offering a PR ?

from versions.

It sounds you should use mvn versions:set -DnewVersion=WhatEver instead which will change the versions of all all modules incl. the parent in your multimodule build. So from my point of view it does not really makes sense to use latest-versions inside a multi module build.

from versions.

@khmarbaise, this is not the described use case. I believe mvn versions:set -DnewVersion=WhatEver simply sets exactly the same new version for all modules starting from parent (rather than updating the versions of dependencies). In other words, versions of dependencies have to be updated, not versions of the modules themselves. The idea is to keep moving to the latest known versions of internal dependencies - fairly common update procedure.

Now, not all dependencies have to be updated.
The dependencies can be split into two categories:

• (A) those which groupId:artifactId match those reachable from parent in multi-module reactor build
• (B) those which groupId:artifactId match those outside of reactor build (external dependencies)

We need to update only those in "category (A)".

For example:

• Any dependency like A, B, C, D, E, F, G and even root in the description are internal to the multi-module reactor build - they are in "category (A)". So, if C is listed as dependency of E, C's version (in dependency list of E) will be updated to the latest known non-snapshot version (because C is part of the same multi-module reactor build as E). Snapshot versions may also be used but it is already covered as additional by includeSnapshots option.
• Any dependency outside like log4j:log4j or org.apache.camel:camel-core will stay at the same versions because neither log4j:log4j or org.apache.camel:camel-core is being built starting from the root (based on example in the description).

Again, it is exactly the opposite to what mvn versions:use-latest-versions with excludeReactor does. What would resolve the case is mvn versions:use-latest-versions with something like includeOnlyReactor.

Note that, in general, all those modules in example (A, B, C, D, E, F, G and even root) may actually have different release cycles (with completely different version numbers) - using the same version number for all is not an option. The only thing in common they have is that they are reachable from root (directly or indirectly) via references in <module> tag and, therefore, they are part of the same multi-module reactor build.

One more point. Even though a module is referenced in <module> tag of its parent, the module may never reference its parent in <parent> tag. In other words, child may not necessarily inherit configuration (what <parent> tag does) - child only get referenced to trigger its inclusion into multi-module reactor build (what <module> tag does).

from versions.

I'd like to note that the suggested includeOnlyReactor flag would be useful with the versions:set goal as well, and perhaps others.

from versions.