[ https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808941#comment-17808941 ]
ASF GitHub Bot commented on MNG-8015: ------------------------------------- desruisseaux commented on code in PR #1378: URL: https://github.com/apache/maven/pull/1378#discussion_r1460555006 ########## api/maven-api-core/src/main/java/org/apache/maven/api/PathType.java: ########## @@ -0,0 +1,143 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.api; + +import java.nio.file.Path; +import java.util.Objects; +import java.util.Optional; + +import org.apache.maven.api.annotations.Experimental; +import org.apache.maven.api.annotations.Nonnull; + +/** + * The option of a command-line tool where to place the paths to some dependencies. + * A {@code PathType} can identify the Java class-path, the Java module-path, + * or another kind of path for another programming language for example. + * This class is like an enumeration, except that it is extensible: + * plugins can define their own kinds of path. + * + * <p>Path types are often exclusive. For example, a dependency should not be both + * on the Java class-path and on the Java module-path.</p> + * + * @see DependencyProperties#PATH_TYPES + * @see org.apache.maven.api.services.DependencyResolverResult#getDispatchedPaths() + * + * @since 4.0.0 + */ +@Experimental +public abstract class PathType { Review Comment: The `JavaPathType` focuses on the standard Java tools. In order to avoid being opinionated, the current strategy is to take the [Java Development Kit Version 21 Tool Specifications](https://docs.oracle.com/en/java/javase/21/docs/specs/man/index.html) and put all options for all kinds of path in the `JavaPathType` enumeration. So this is non-arbitrary from a Java standard point of view. If there is a demand for other popular types of path, I suppose that they could be added to this enumeration as well. But even if they are not added, all plugins have the possibility to provide their own `PathType` enumeration if they want. The `PathType.option()` method could indeed be controversial. The reason for this API is because some options are formatted is a special way. Currently, `--patch-module` is the only example I'm aware of, but more may exist. This architecture makes possible to handle those special cases in dedicated `PathType` implementations. The presence of this API in a shared place is because _Java Development Kit Version 21 Tool Specifications_ uses those options consistently in all tools as far as I know. For `PathType` defined in plugins, the plugin has the possibility to provide the right option for the tool that they target. Note: `JavaPathType` is currently not the only Java-specific interface in core. There is also `JavaToolchain`. > 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)