[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814127#comment-17814127
]
ASF GitHub Bot commented on MNG-8015:
-------------------------------------
desruisseaux commented on PR #1378:
URL: https://github.com/apache/maven/pull/1378#issuecomment-1925933959
Added Javadoc on shortcut methods in `Session` interface. Sometime I had to
guess, and there is questions previously flagged by `@todo` tag in b72d1ce. The
test case gives the impression that the answer to those questions is that the
dependency given in argument is included in the returned list, but it would be
nice to said that in the javadoc if it is the case.
Added a convenience method:
```java
@Nonnull
Map<PathType, List<Path>> resolveDependencies(
@Nonnull DependencyCoordinate dependencyCoordinate,
@Nonnull PathScope scope,
@Nonnull Collection<PathType> desiredTypes);
```
Expanded an existing test case: after fetching the dependency paths, fetch
again the same dependency paths but this time dispatched by type.
* First invoke above convenience method with
`Arrays.asList(JavaPathType.CLASSES, JavaPathType.MODULES)`:
* The `pom` dependency is excluded, because it is placed neither on the
class-path or module-path.
* The `junit` dependency appears on the module-path because it has as
`Automatic-Module-Name` attribute.
* All other dependencies are on the class-path.
* Invoke the same method again, but this time with only
`Arrays.asList(JavaPathType.CLASSES)`:
* The `junit` dependency is now on the class-path.
* This is the mechanism by which a plugin can tell that it is not
interested in JPMS.
**Note:** A test if failing in the "Maven Core ITs suite" module:
```
Error: MavenITmng5135AggregatorDepResolutionModuleExtensionTest.testit:61-
AbstractMavenIntegrationTestCase.assertTrue:359 [test-classes, classes]
==> expected: <true> but was: <false>
```
I don't know what is happening here. A search for
`AbstractMavenIntegrationTestCase` in my repository clone found nothing.
> 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)
