Support multi-module builds (regression in 3.26) #397
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Steps to reproduce
When building a plugin against a plugin parent POM that is in the same multi-module project, the build fails.
Stack trace
Evaluation
The problem was introduced in #314 which removed the explicit setting of remote repositories. That made us reliant on https://github.com/apache/maven/blob/c6ecff9923088d854d4621e17d602f1c70dda806/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java#L873, which is fine when the parent POM is a deployed artifact. But the if statement surrounding that line is never true when the parent POM is part of the same multi-module build, resulting in the above stack trace.
Solution
Partially revert #314 by setting the remote repositories of the project building request to the project's current value at the time the resolution request is made (after the second phase of POM resolution is complete and the remote repositories are available in the model).
This is admittedly a fringe use case: none of our CI builds do things this way, nor am I aware of anyone else who has requested this functionality. But I have been doing multi-module builds like this in some local experiments, and I would like it to be supported. Moreover, I do not think that this PR is making the codebase harder to maintain or precluding any existing use cases, so why not support this use case as well. A final argument in favor of supporting this use case is that it used to work prior to 3.26.
Testing done
Confirmed that the steps to reproduce no longer result in the above stack trace with this fix.