[MRESOLVER-354] Document Expected Checksums in Resolver #281
Conversation
| ## Transport Checksum Strategies | ||
|
|
||
| Historically, the "obtain expected checksum" was implemented as simple HTTP GET | ||
| request against Artifact checksum URL (Artifact URL appended by ".sha1"). This logic |
There was a problem hiding this comment.
Note that this is actually transport specific.
There was a problem hiding this comment.
removed mention of HTTP GET
cstamas
changed the title
| means, possibly ahead of any transport operation. There is an SPI extension point that users may | ||
| implement, to have own ways to provide checksums to resolver. Alternatively, one may use Resolver out of the |
There was a problem hiding this comment.
An example implementation or demo - how to implement will be helpful, can be on separated document.
| provided by user. This new feature may become handy in cases when user does not trust the local | ||
| repository, as it may be shared with some other unknown or even untrusted party. | ||
|
|
||
| The Trusted Checksums provide two source implementations out of the box. |
There was a problem hiding this comment.
example how to configure, which property to set ... etc will be appreciated, can be as link to other document
|
@slawekjaranowski re examples, all the new features (RRF, TrustedChecksums) are kinda incomplete without https://issues.apache.org/jira/browse/MRESOLVER-304 (or linked Maven issue https://issues.apache.org/jira/browse/MNG-6303) as ultimate goal would be to commit checksums, filter config along with project sources. Sadly, that is impossible today. So I'd rather wait with examples. But still, this doco is useful, as it explains at least one confusion users hit (and reported as "bug" while it was actually OK) https://lists.apache.org/thread/nsbormhpfgqq19qzgo4rx12lg28qv0tb |
Add documentation to new resolver transport features like "provided" and "remote included" checksums. Also explain "trusted" checksums.
https://issues.apache.org/jira/browse/MRESOLVER-354