[
https://issues.apache.org/jira/browse/MNG-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874168#comment-17874168
]
ASF GitHub Bot commented on MNG-8195:
-------------------------------------
gnodet merged PR #1625:
URL: https://github.com/apache/maven/pull/1625
> Add DependencyResolverResult.getModuleName(Path) method
> -------------------------------------------------------
>
> Key: MNG-8195
> URL: https://issues.apache.org/jira/browse/MNG-8195
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
> Reporter: Tamas Cservenak
> Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-4
>
>
> Clarify the meaning of "module" in documentation, then add two methods for
> getting Java module information from a `DependencyResolverResult`:
> * `getModuleName(Path)` returns a `java.lang.String`
> * `getModuleDescription(Path)` returns a `java.lang.module.ModuleDescriptor`
> "Get name" may seem redundant with "get description" because the name can be
> obtained from the description by `ModuleDescriptor.name()`. The difference is
> that "get name" fallbacks on the `Automatic-Module-Name` attribute of
> `META-INF/MANIFEST.MF` if the module descriptor is not found.
> The rational for providing those methods in the API is because it allows to
> use the cache managed by the `DefaultDependencyResolverResult`
> implementation. It avoids decoding many times the `module-info.class` files.
> Plugins need those information for managing `--add-reads` and similar options.
> Alternative: It would be more natural to have `getModuleName()` and
> `getModuleDescription()` methods in `Dependency`. But it would imply that
> dependency contains a `getPath()` method. I'm not sure why it is not already
> the case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
