Hello all
Following the recommendations in the "Guidance on Maven 4 API issue"
thread, I refactored the proposal. The new commits (only 2 at this time)
replace the previous ones.
Commit 1
The first commit [1] adds the following constants in the API:
* In Type interface: POM, JAR, CLASSPATH_JAR, MODULAR_JAR,
JAVA_SOURCE, JAVADOC, TEST_JAR (see note below for December 14 change).
* In DependencyProperties interface: FLAG_MODULE_PATH_CONSTITUENT,
FLAG_PATCH_MODULE.
The isAddedToModulePath() method is no longer introduced. Instead, this
commit deprecates isAddedToClasspath() methods because checking this
boolean value is not sufficient for determining if a dependency should
be on the classpath.
The change in the MavenProject class are only factorization for reducing
code duplication and should not have behavioural impact. It is a
side-effect of the previous version of JPMS support proposal, with the
new methods removed.
Note: I noticed that a commit on December 14th removed the POM, JAR,
etc. constants from the Type interface. So I suspect that my first
commit needs to be changed, but I'm not sure how. Where those constants
are supposed to be now, or has the "type" approach changed?
Commit 2
The second commit [2] add a new "enumeration" in the API: PathType. This
is actually implemented as a class for allowing extensions, but should
be understood as an enumeration. The enumeration contains the following
values:
* CLASSES for the --class-path option
* MODULES for the --module-path option
* UPGRADE_MODULES for the --upgrade-module-path option
* PROCESSOR_CLASSES for the --processor-path option
* PROCESSOR_MODULES for the --processor-module-path option
* AGENT for the -agentpath option
* DOCLET for the -doclet option
* TAGLET for the -tagletpath option
* patchModule(String moduleName) for the --patch-module option
The latter is the reason why this enumeration cannot be a
java.lang.Enum. Another reason is for allowing plugins to define their
own enumeration values. Then, this commit add a new method in
DependencyResolverResult:
Map<PathType, List<Path>> getDispatchedPaths();
Above method is like getPaths(), but returns a distinct List<Path> for
each PathType instead of a single list mixing all kinds of path. The
PathType of each dependency is fully determined by the
DependencyProperties, which are themselves determined by the Type (at
least before the December 14th commit), except in the following cases:
* If the type is "jar" instead of "classpath-jar" or "modular-jar",
then an heuristic rule similar to Maven 3 is applied.
* If the type is "test-jar", a more complex analysis is done for
inferring the --patch-module option value.
* The main and test output directories also needs some analysis for
inferring which Java 9+ compiler layout is used (package hierarchy
versus module hierarchy).
Finally, this commit adds an implementation of above methods. In the
DefaultDependencyResolver class, the DefaultDependencyResolverResult
inner class has been extracted as a top-level class for making room for
more development. Then the resolve(DependencyResolverRequest) has been
refactored, but this refactoring should not change the way that the
existing `dependencies` and `paths` collections were populated. Then new
codes were added for populating the above-cited `dispatchedPath` map.
This is not yet tested, but before working on tests and would like to
know what need to be changed (I suspect some changes will be needed,
e.g. regarding Type constants).
Thanks,
Martin
[1]https://github.com/Geomatys/maven/commit/d05c51bd0f5fa5610b744ef66f159128303a67d7
[2]https://github.com/Geomatys/maven/commit/322dffddeb18d7acaea4a3670966dd5f8aeb4add
