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).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
