Apologies if this was already covered somewhere else, but would (or could)
path accumulation support multi-release JAR layouts for all cases (whether
it be modular or class-path JARs or filesystem paths)?
On Tue, Jan 2, 2024 at 10:13 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> 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> getDispatchedPaths();
>
> Above method is like getPaths(), but returns a distinct List 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
>
--
- DML • he/him
