[
https://issues.apache.org/jira/browse/MRESOLVER-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-242:
--------------------------------------
Description:
On remote transfer, if layout does not provide remote checksums (as Javadoc
states: it MAY return empty collection), remote transfer either WARNs or fails
(if repository policy is WARN of FAIL respectively) always. This is wrong IMHO.
OTOH, layout intentionally does not return remote checksums in some cases, like
GPG signature is, if the default Maven2RepositoryLayoutEx is used.
Hence, this causes that (sub)artifacts like checksums and signatures are NOT
resolvable using resolver, due that above (they are deemed to always fail).
Hence, a proposed solution is:
* change of semantics: when layout does not provide remote checksums, skip
checksum validation of remote checksums (as there is no such thing as "checksum
of a checksum" or in many cases "checksum of a signature").
* make resolver layout extensible re "artifacts with omitted checksums" instead
to have baked in only one extension: {{.asc}}
was:
On remote transfer, if layout does not provide remote checksums (as Javadoc
states: it MAY return empty collection), remote transfer either WARNs or fails
(if repository policy is WARN of FAIL respectively) always. This is wrong IMHO.
OTOH, layout intentionally does not return remote checksums in some cases, like
GPG signature is, if the default Maven2RepositoryLayoutEx is used.
Hence, this causes that (sub)artifacts like checksums and signatures are NOT
resolvable using resolver, due that above (they are deemed to always fail).
Hence, a proposed solution is:
* change of semantics: when layout does not provide remote checksums, skip
checksum validation of remote checksums (as there is no such thing as "checksum
of a checksum" or in many cases "checksum of a signature").
* make resolver layout "aware" of signatures, just like it is aware of
checksums and make them extensible/configurable
Optionally:
* implement signing/signature verification services
> When no remote checksums provided by layout, transfer inevitably fails/warns
> ----------------------------------------------------------------------------
>
> Key: MRESOLVER-242
> URL: https://issues.apache.org/jira/browse/MRESOLVER-242
> Project: Maven Resolver
> Issue Type: Bug
> Reporter: Tamás Cservenák
> Assignee: Tamás Cservenák
> Priority: Major
> Fix For: 1.8.0
>
>
> On remote transfer, if layout does not provide remote checksums (as Javadoc
> states: it MAY return empty collection), remote transfer either WARNs or
> fails (if repository policy is WARN of FAIL respectively) always. This is
> wrong IMHO.
> OTOH, layout intentionally does not return remote checksums in some cases,
> like GPG signature is, if the default Maven2RepositoryLayoutEx is used.
> Hence, this causes that (sub)artifacts like checksums and signatures are NOT
> resolvable using resolver, due that above (they are deemed to always fail).
> Hence, a proposed solution is:
> * change of semantics: when layout does not provide remote checksums, skip
> checksum validation of remote checksums (as there is no such thing as
> "checksum of a checksum" or in many cases "checksum of a signature").
> * make resolver layout extensible re "artifacts with omitted checksums"
> instead to have baked in only one extension: {{.asc}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
