desruisseaux commented on PR #3395:
URL: https://github.com/apache/maven-surefire/pull/3395#issuecomment-5037505480
Please correct me if I'm wrong, but I have the impression that the strategy
implemented in this pull request is to analyse the classpath and determine
automatically which dependencies to move to the module path, based on whether
the dependency is a module referenced by the project. This is indeed the only
strategy possible with Maven 3, but Maven 4 offers a quite different approach
in the "give control to developer" spirit.
If the Maven Surefire community agrees, I think that the time has come to
create a `maven-surefire-plugin-3.x` branch with the current state of `master`,
then move `master` to Maven 4 only, like what we are already doing with Maven
Compiler Plugin and Maven JAR Plugin. I suggest to leave the 3.x branch
unchanged, and focus entirely on the 4.x (now `master`) branch. Any code that
disable some tests on 3.x could then be removed.
Then, I suggest to do the pull requests in the opposite order: focus on the
_class-path versus modul-path_ issue first (the precondition in the third
bullet of this issue description) because, as the description rightfully said,
it is a critical prerequisite on which all other work will be based on. In the
current state of #3392 and #3395, the _class-path versus module-path_ issue
could not be resolved first because, if done automatically (as my understanding
on the current state of this pull request), this process is outside developer's
control and would therefore break existing projects. But if done in the Maven 4
way, this process is fully under developer's control, and therefore can be done
first without breaking any existing projects or tests.
The Maven 4 way is to not try to guess where to put the dependencies (except
in a compatibility mode discussed below), but instead invite the developers to
said explicitly what they want. It can be done with a code like below (I'm
copying some lines from the Maven Compiler Plugin with some editions). Note
that the same code can be used for both modular and non-modular project, this
is the purpose of the `isModular` flag:
```java
var allowedTypes = EnumSet.of(JavaPathType.CLASSES);
if (isModular) {
allowedTypes.add(JavaPathType.MODULES);
}
DependencyResolver resolver = session.getService(DependencyResolver.class);
DependencyResolverResult dependencies =
resolver.resolve(DependencyResolverRequest.builder()
.session(session)
.project(project)
.requestType(DependencyResolverRequest.RequestType.RESOLVE)
.pathScope(PathScope.TEST_RUNTIME)
.pathTypeFilter(allowedTypes)
.build());
Map<PathType, List<Path>> dependencies =
dependencyResolution.getDispatchedPaths();
```
With above code, the `dependencies` map already separated the module-path
from the class-path. In Maven 4 spirit, this separation is no longer plugin's
responsibility. It is now managed by Maven core itself. This is important for
ensuring that we get the same separation in all plugins. In this case, for
making sure that we have the same separation during the execution of tests than
what has been used for compilation.
Maven 4 core makes its decision based on the `<type>` element declared in
plugins. If `<type>modular-jar</type>`, it is unconditionally placed on the
module-path. If `<type>classpath-jar</type>`, it is unconditionally placed on
the class-path. If `<type>modular-jar</type>` (the default), the same heuristic
rules as Maven 3 are applied. The latter exists for compatibility reasons, but
I suggest to consider it as deprecated in the context of modular projects.
However the consequence should be that we can implement this feature first,
existing projects would hopefully not be impacted if the developers do not
request `<type>modular-jar</type>` explicitly.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
