[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:07 PM:
--------------------------------------------------------------
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps, that not only did pull updates but "fixed" the
corruption in local repo as well)
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
> 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)
