Howdy, no, old stuff (Maven3) should not be touched. All the merged changes (and artifact properties) are visible on "new" Maven4 APIs ONLY. There is "no hope" for Maven3 in this respect, as it cannot be done w/o breaking stuff... (maybe it can, but would be "expensive" regarding effort).
Hence I'd recommend to focus of new API and hence, plugins using these should be maven4 plugins Here is for example m-compiler-p ported to new API: https://github.com/gnodet/maven-compiler-plugin/tree/m-api Thanks T On Mon, Dec 11, 2023 at 4:50 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > 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/ > >
