[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809118#comment-17809118
]
ASF GitHub Bot commented on MNG-8015:
-------------------------------------
rmannibucau commented on code in PR #1378:
URL: https://github.com/apache/maven/pull/1378#discussion_r1460903860
##########
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:
> There is an official thing called Java® tools specification
True but this is unrelated to this PR by the fact maven does not aim to
target this scope but way more so question is do we put all we intend to
support in core or not.
For me answer can only be no otherwise core would quickly be bloated and we
already saw it does not scale in time (in terms of maintenance).
So overall you can reference any trademark but this stays out of topic for
me, topic is what is the scope of core and it is the pipeline only for me and
hopefully we'll be able to drop mvn 2 legacy remaining parts not respecting
that historically.
> This is not the case of WAR, EAR, OSGi, etc.
Once again it is out of topic but there are a lot of shared parts there too
so if you reasoning is right then we must embrace that too (it is default maven
plugins too after all).
> If you want Maven core to be language neutral and move all Java-specific
stuff in a separated module shared by all Java plugins, I have no objection.
Exactly.
> But this is a separated debate (JavaPathType is not the only Java-specific
thing currently in core).
Not really, the point is that `JavaPathType` has not to exist in core but in
`maven-java-tool-shared` module (whatever name it is). Core can stick to
`String` since `option` doesnt always makes sense.
> 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)
