[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806292#comment-17806292
]
ASF GitHub Bot commented on MNG-8015:
-------------------------------------
desruisseaux opened a new pull request, #1378:
URL: https://github.com/apache/maven/pull/1378
Introduces new API described in JIRA issue
[MNG-8015](https://issues.apache.org/jira/browse/MNG-8015):
* `PathType` enumeration-like class.
* `JavaPathType` subtype with values such as `MODULES`, `CLASSES`, `DOCLET`,
`TAGLETS`, _etc._
* `PATH_TYPES` dependency property key (as a side-effect, the
`DependencyProperties` API is modified for making it type-safe).
* `DependencyResolverRequest` API for allowing plugins to specify the
`PathType` that the plugin wants.
* `DependencyResolverResult.getDispatchedPath()` method for getting the
result: the paths to dependencies for each path type.
# Open issues
Commit 9c5e9ff412718e4ad29299ea79ba0d158c27d43d (which add implementation)
introduces a dependency to Java 9 or later (the `ModuleDescriptor` class). If
Maven 4 decides to stay executable on Java 8, this part will need to be
refactored in a multi-version JAR file. If Maven 4 decides to require Java 9 or
later, the `source` and `target` options in the `pom.xml` file should be
replaced by a `release` option.
The implementation has no JUnit tests yet, so it may contain bug. We may
want to write JUnit tests before to integrate this pull request. Waiting to see
if a discussion causes a modification of this proposal before to write tests.
> Control the type of path where each dependency can be placed
> ------------------------------------------------------------
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
> Affects Versions: 4.0.0-alpha-12
> Reporter: Martin Desruisseaux
> Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{<type>jar</type>}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{<type>modular-jar</type>}} implies {{PathType.MODULES}} only.
> * {{<type>classpath-jar</type>}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
> specify that it is interested in {{PathType.CLASSES}} and
> {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared
> that it can be placed on the class-path or the doclet-path, only the
> class-path is left after intersection with plugin's request. This is
> important for the next step.
> If, after all filtering such as above paragraph are applied, a dependency has
> only one {{PathType}} left, then there is no ambiguity and we are done.
> Combined with above-cited dependency types like {{modular-jar}} or
> {{classpath-jar}}, this rule allows users to control where the dependency
> will be placed. But if there are two or more {{PathType}} left after
> filtering, then a choice needs to be done. For example if there are both
> {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when
> {{<type>jar</type>}} is used), then an heuristic rule similar to Maven 3 can
> be applied: check if a {{module-info.class}} file or an {{Automatic-Name}}
> manifest attribute is present, and base the decision on that.
> This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
