-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MNG-8015] Control the type of path where each dependency can be placed #1401
Conversation
@desruisseaux fwiw, the failing test is an integration test. which belongs to the https://github.com/apache/maven-integration-testing repository and not https://github.com/apache/maven ... |
By looking at this PR, one thing occurred to me: today resolver-only users (those integrating Resolver w/o Maven) are able to fully resolve things as Maven would. If any of these become implemented in maven-core (as opposed to maven-resolver-provider), this "functional equivalence" is gone: JPMS will become handled by Maven, but Resolver integrators will not be able to resolve projects that do use these new functionalities. We need to keep eye on this fact. |
Ideally, we'd come up with a way to use Maven 4 API outside of maven... |
That sound awkward to me 😄 like saying "we will make servlet-api usable without servlet engine", so something will need to implement it. And if not Maven, what? |
Maven has all the container side: parsing the projects, analyzing the build and launching all the mojos in sequence. That part is not really in the Maven 4 API which is about using maven model and resolver (well, apart from the Project). But if we can provide a |
While I understand the technical relevance we should also likely discourage it since one of the goal is to own and not conflict without anything possible. |
I'm not familiar with the relationship between Maven and Resolver. But if the
The only heuristic part is what to do when the intersection of the above contains 2 or more paths. |
0477c52
to
b4caaeb
Compare
As a real world use case for testing the Maven improvements, there is the following scenario: a project depends on JUnit 5 with For a mysterious reason, Maven 3 places The reason why JUnit 5 cannot access its own classes is because jar --describe-module -f junit-platform-commons-1.10.2.jar Output snippet (reformatted):
Because Maven puts A workaround is to add the following lines in Surefire configuration for breaking module encapsulation: <argLine>
--add-exports org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
--add-exports org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
</argLine> We should not be forced to apply such workaround. This real use case is another demonstration of the need to improve JPMS handling compared to what Maven 3 does. For testing if this pull request achieves that goal in Maven 4, we can test if it allows us to remove the above hack from GeoAPI conformance pom.xml file. |
@desruisseaux I'm not sure I understand the proposal, the "workaround" is needed per java, do you want surefire to do it implicitly or just use the right path? Isn't it solved by the type work you did and Guillaume reuses in maven 4? (trying to convert the statement in actions) |
The workaround is not needed per Java. It is needed because Maven 3 mixes class-path and module-path in an apparently random way. It is an example of case where putting the JAR on the class-path breaks the application. Just putting the This problem should indeed by solved by the path work. I reported this story as a real use case for testing that the proposal works. The criterion for considering that test as successful is to be able to remove any hacks in above-cited |
Ok, so no action needed. side note: it is not random but an heuristic so does not always work indeed - don't ask me why default is not 100% the classpath, it is statically saner for 3rd parties even if it enforces more work for jpms apps, but we see the light so we'll drop it soon 🤞 . |
Should we go ahead and merge that one ? It does not really affects the current behaviour, so if we even find something missing, we can still fix it later... |
Fine for me. I added one more commit for allowing plugins to log warning to users when a dependency cannot be placed on any path. After the merge, I would like to try the new API in |
Sounds good. You'll need to build the following branches:
The above maven-compiler-plugin PR can be used as a basis, as it is already has all the migration to the v4 api. If the underlying plexus-compiler API does not support the needed features to fully leverage the new jpms support, a possibility would be to change the m-compiler-p to simply wrap the |
eafb3d1
to
0c8a124
Compare
WooHoo! 🎆 |
Thanks! I will try to start playing with the compiler plugin this weekend. |
I have not explored the Plexus compiler capabilities, but indeed I propose to use |
#1378 merged with master and pushed to maven so that we can actually collaborate on it (as the branch for #1378 is not writable)