[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:41 PM:
--------------------------------------------------------------
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in releases repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
> Fix behaviour of the maven update policy
> ----------------------------------------
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
