Hello all
Thanks Tamás for the review.
Le 2023-12-06 à 11 h 50, Tamás Cservenák a écrit :
Still, these changes are not mandatory anymore, as the properties
makes these extensible (and the isXXX method are "just" shortcut methods).
The problem is that the MavenProject class (the main consumer of those
information) has no access to DependencyProperties. Instead, it uses
Artifact and ArtifactHandler, which are defined in the "maven-artifact"
module. But that module does not depend on the "maven-api-core" module
where DependencyProperties is defined. So it seems that in current Maven
architecture, those information can only be transferred by copying them
in isAddedToClassPath or isAddedToModulePath properties.
I would like to remove those two properties because they are confusing
("added" are really "addable") and insufficient (I already have a need
for a third kind of path: --patch-module options). They would be
replaced by DependencyProperties. But for making that possible, one of
the following actions would need to be done:
* Add "maven-api-core" dependency in "maven-artifact".
* Merge those two modules in a single one (I would love to see Maven
reduce the amount of modules, for making easier for newcomers to
navigate in the code base).
* Other possibility that I forgot?
Which one should be done?
I'd now rather go with packaging types and artifact types and see what
we need on that front...
It will be my next iteration. For now I have applied the following changes:
* Rebased the commits on alpha10-SNAPSHOT.
* Removed the "cmod-jar" in my previous proposal, replaced by
"classpath-jar".
* Created a wiki page for describing the meaning of proposed artifact
types [1].
* Add a new checked exception, InvalidDependencyException, as the base
class of the existing DependencyResolutionRequiredException, and
modified MavenProject API to throw that exception, because we may
fail to use a dependency for other reasons (e.g.,
StrictlyModularDependencyException from previous email). That change
would need to be propagated in plugins, but this is mostly a
search-and-replace.
* Add a new DependencyPaths interface in Maven API. It provides
class-path, module-path and patch-module in a single object, because
those paths needs to be determined together. Building those paths
separately in independent methods is not practical.
* Add getCompilePathElements(), getTestPathElements() and
getRuntimePathElements() methods in MavenProject, which return
above-cited DependencyPaths.
See [2] for the 3 commits were above changes are introduced.
This prototype has a dependency to Java 9 because it needs to use
java.lang.module.ModuleDescriptor for fetching module information.
However, if this proposal is accepted (after completion), this Java 9
dependency would move to the META-INF/versions/9 directory of a
multi-versions JAR file.
Feedback welcome. I will wait for evaluation before to continue, if the
community agrees with this proposal (or at least its goals).
Note: the new InvalidDependencyException could be taken without waiting
for the completion of the rest of the proposal. There is really many
reasons why building a path may fail, independently of modularization.
The exception should not be restricted to the "resolution required"
reason only.
Martin
[1]https://github.com/Geomatys/maven/wiki/Explicit-module-path
[2]https://github.com/Geomatys/maven/commits/explicit-module-path/
