[
https://issues.apache.org/jira/browse/MNG-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8195:
---------------------------------
Description:
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.
was:
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.
> 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)
