Howdy, looks good for a start... Still, these changes are not mandatory anymore, as the properties makes these extensible (and the isXXX method are "just" shortcut methods).
I'd now rather go with packaging types and artifact types and see what we need on that front... Thanks T On Tue, Dec 5, 2023 at 1:03 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Started proposed changes in a Maven clone (work in progress). Highlights: > > * In the DependencyProperties interface, added a > FLAG_MODULE_PATH_CONSTITUENT in complement to the existing > FLAG_CLASS_PATH_CONSTITUENT [1]. > * Added corresponding isAddedToModulePath() methods and > implementations beside most existing isAddedToClassPath() > occurrences (e.g. [2]). > * Add Javadoc with following contract: the "added to class-path" and > "added to module-path" flags are not necessarily mutually exclusive. > If both flags are set, it means that the dependency can work in both > places (by contrast, a dependency with only the "added to module > path" flag means that it cannot run on the class-path). I have used > the "added" word for consistency with current usage, but it should > rather be understood as "addable". > * Added a StrictlyModularDependencyException to be thrown when a user > wants to put on the classpath a dependency which has only the > "(addable) to module-path" flag. Maybe it should be a warning > instead of an exception. > * Modified the MavenProject implementation in accordance with above > contract [3]. The behaviour should be identical to previous > implementation in projects with only classical JAR dependencies. The > idea is that existing methods (getCompileClasspathElements(), > getTestClasspathElements(),getRuntimeClasspathElements()) would be > invoked by plugins that do not want to care about module path. As > long as the StrictlyModularDependencyExceptionis not thrown, it > should be safe to ignore module path. New methods for (classpath + > module path) will be added later. > * Added two new types [4]: > o "modular-jar" for JARs that must be on the module-path. "Modular > JAR" is the term used in Oracle documentation for JAR with > module-info. > o "cmod-jar" for modular JARs that should be on the module-path, > but work also on the classpath. "CMod" can be understood as > "classpath or module-path" or as "compatible module". > > Of course this is subject to changes according feedback. > > Martin > > [1] > https://github.com/Geomatys/maven/commit/eb6839be18b4d3df042522545c5914c364f3d8ce#diff-e4dfc0df29eed1a4c86581da84309d85fa12702b832555b60d86106c2af8550dR49 > [2] > https://github.com/Geomatys/maven/commit/eb6839be18b4d3df042522545c5914c364f3d8ce#diff-b1e0e6b9b7fa80c2facbaa5ac40d839594a2854747afc70572445cb9cbeeab2cR91 > [3] > https://github.com/Geomatys/maven/commit/eb6839be18b4d3df042522545c5914c364f3d8ce#diff-ea86e9c1e8def45475c1f03fc335686165184ec2ab190054f5c8b7b77c4414f4R343 > [4] > https://github.com/Geomatys/maven/commit/eb6839be18b4d3df042522545c5914c364f3d8ce#diff-b1e0e6b9b7fa80c2facbaa5ac40d839594a2854747afc70572445cb9cbeeab2cR47 >
