[MNG-7629] Improve resolution of modules within a multi-module build

[jira-importer]

Guillaume Nodet opened MNG-7629 and commented

---

Issue Links:

• MNG-6442 Run tests with Maven on pre-compiled project

• MNG-3043 Allow 'mvn test' to work with test-jar dependencies in a reactor

• MNG-6118 Allow resolving inter-module dependencies when using --file

Remote Links:

• GitHub Pull Request #219
  
• GitHub Pull Request #234
  
• GitHub Pull Request #912
  
• GitHub Pull Request #954
  

Backported to: 4.0.0-alpha-4

[jira-importer]

Guillaume Nodet commented

The PR merged for MNG-6118 comes with a bunch of problems, as resuming a build fails if the build is using attached artifacts, as those are not resolved. It also slows down things a lot when you want to build only a subtree in a big reactor (the POM parsing time can take a few seconds).

The proposal is to revert #373 to restore the previous behaviour.

The original issue could be solved by introducing a "project local repository manager" somehow, see discussion that happened between Tamas Cservenak, gnodet and Maarten Mulders at https://the-asf.slack.com/archives/C7Q9JB404/p1669927302914189.

[jira-importer]

Maarten Mulders commented

I don't like the idea of "reverting" things that obviously provide value by solving a particular user problem. If there are issues with the implementation of that issue, let's find, discuss and fix those issues. But reverting a solution without a plan of properly addressing the issue would generally get a -1 from my side: it swaps one problem for the other.

Could we rephrase this issue, for example like "Improve resolution of modules within a multi-module build"?

[jira-importer]

Guillaume Nodet commented

I did point to a proposal. Here's a summary which needs to be discussed. However, there are real problems that can't be fixed imho with the current solution.

My proposal would be to introduce a project local repository in ${maven.multiModuleProjectDirectory}/target/build that would be used in the package phase to install the locally built artifacts and to resolve them.
This would allow to run mvn package && mvn jetty:run -f webapp even if the build uses attached artifacts. This would also be closer to a real build, as using target/classes instead of resolving the packaged artifacts does assume that the classes files are not tampered with during the package phase, which is the case with some plugins like the m-shade-p for example.

[jira-importer]

Guillaume Nodet commented

As a sample project which exhibits problem, run the following commands:

git clone https://github.com/apache/maven
cd maven
git checkout 984f73dc7ca2515ee520fbded3382820f62116e9
mvn install -DskipTests
mvn install -DskipTests -f maven-settings

[jira-importer]

Guillaume Nodet commented

Also, in this case, given it breaks a bunch of things, I would think the previous PR (which aims to address new use cases) should have deserved a -1, not the revert (which reverts to a proper behaviour). But let's let that aside and discuss what can be done.
As for the name of the title, please rephrase at will. I think ultimately, the title may contain a hint of the future solution, so I don't care about it for now.