[ https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817641#comment-17817641 ]
ASF GitHub Bot commented on MNG-8015: ------------------------------------- desruisseaux commented on PR #1401: URL: https://github.com/apache/maven/pull/1401#issuecomment-1945902723 As a real world use case for testing the Maven improvements, there is the following scenario: a project depends on JUnit 5 with `compile` scope (because the project is a conformance test kit). Everything is JPMS: the project, JUnit 5 and their dependencies. JUnit 5 is itself splitted in many modules, including the `junit-jupiter-api`, `junit-jupiter-engine` and `junit-platform-commons` modules. For a mysterious reason, Maven 3 places `junit-platform-commons` dependency on the module path, but `junit-jupiter-engine` on the class-path (verified with `mvn test --debug`). The consequence is that JUnit 5 cannot be launch. The JVM refuses to start with the following error message: _"class org.junit.platform.engine.discovery.DiscoverySelectors (in unnamed module @0x3b2c72c2) cannot access class org.junit.platform.commons.util.Preconditions (in module org.junit.platform.commons) because module org.junit.platform.commons does not export org.junit.platform.commons.util to unnamed module @0x3b2c72c2"_. Translation: **JUnit 5 cannot access its own internal classes!** The reason why JUnit 5 cannot access its own classes is because `junit-platform-commons` allows access to its packages only to other JUnit 5 modules. It can be seen with the following command: ```bash jar --describe-module -f junit-platform-commons-1.10.2.jar ``` Output snippet (reformatted): ``` qualified exports org.junit.platform.commons.util to org.junit.jupiter.api org.junit.jupiter.engine etc... ``` Because Maven puts `junit-platform-commons` on the module-path, access restrictions to that JAR are enforced. But because Maven puts `junit-jupiter-engine` on the class-path, that module is unnamed and consequently not recognized as a module in above list of modules allowed to access the `junit-platform-commons` internal packages. Thus the failure to launch JUnit. A workaround is to add the following lines in Surefire configuration for breaking module encapsulation: ```xml <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](https://github.com/opengeospatial/geoapi/blob/9e4ff919ef56e52e05767cc85c88e5795081c883/geoapi-conformance/pom.xml#L133). > Control the type of path where each dependency can be placed > ------------------------------------------------------------ > > Key: MNG-8015 > URL: https://issues.apache.org/jira/browse/MNG-8015 > Project: Maven > Issue Type: Improvement > Components: Core > Affects Versions: 4.0.0-alpha-12 > Reporter: Martin Desruisseaux > Priority: Major > > Make possible to declare where each dependency can be placed: on the > module-path, class-path, agent path, doclet path, taglet path, annotation > processing path, _etc._ The proposed improvement consists in adding a new > {{PATH_TYPES}} property that can be associated to dependencies. The property > value is an array of {{PathType}}, a new enumeration-like class with values > such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java > enumerations, this enumeration-like class is extensible: plugins can add > their own enumeration values. This is required at least for the > {{--patch-module}} option, where a new {{PathType}} enumeration value need to > be created for each module to patch. > Users can control indirectly the {{PathType}} of a dependency by specifying > the dependency type. Note that there is no direct mapping between the > dependency type and where the dependency will be placed, but only an indirect > mapping caused by the fact that using a dependency type implies implicit > values of some properties such as classifier, and (with this proposal) path > types: > * {{<type>jar</type>}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}. > * {{<type>modular-jar</type>}} implies {{PathType.MODULES}} only. > * {{<type>classpath-jar</type>}} implies {{PathType.CLASSES}} only. > * _etc._ > When a plugin requests the paths of dependencies, the plugin specifies the > types of path it is interested in. For example, a Java compiler plugin can > specify that it is interested in {{PathType.CLASSES}} and > {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared > that it can be placed on the class-path or the doclet-path, only the > class-path is left after intersection with plugin's request. This is > important for the next step. > If, after all filtering such as above paragraph are applied, a dependency has > only one {{PathType}} left, then there is no ambiguity and we are done. > Combined with above-cited dependency types like {{modular-jar}} or > {{classpath-jar}}, this rule allows users to control where the dependency > will be placed. But if there are two or more {{PathType}} left after > filtering, then a choice needs to be done. For example if there are both > {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when > {{<type>jar</type>}} is used), then an heuristic rule similar to Maven 3 can > be applied: check if a {{module-info.class}} file or an {{Automatic-Name}} > manifest attribute is present, and base the decision on that. > This proposal aims to fix MNG-7855. -- This message was sent by Atlassian Jira (v8.20.10#820010)