[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750731#comment-17750731
]
ASF GitHub Bot commented on MNG-7802:
-
cstamas commented on PR #1144:
URL: https://github.com/apache/maven/pull/1144#issuecomment-1663893897
To be done in resolver 2.0.0, please once out upgrade to this instead
https://issues.apache.org/jira/browse/MRESOLVER-377
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731581#comment-17731581
]
ASF GitHub Bot commented on MNG-7802:
-
gnodet commented on PR #1144:
URL: https://github.com/apache/maven/pull/1144#issuecomment-1587196633
Will update the PR when https://github.com/apache/maven-resolver/pull/297 is
released.
> 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
> Fix For: 4.0.x-candidate
>
>
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728950#comment-17728950
]
Tamas Cservenak commented on MNG-7802:
--
Part of the fix may be this (resolver) change:
[https://github.com/apache/maven-resolver/pull/297]
For this to be complete, things needed:
* maven3.x in session factory always sets
{{aether.updateCheckManager.updatePolicyScope=all}} to make Resolver work in
"old" way, so this change
* maven4.x does NOT set (so obey resolver default OR user set configuration),
BUT it should implement following changes as well: make default values (when
not given) "daily" policy, also make sure that "built in" central repo also
have "daily" policy. This way, Maven4 would effectively solve the problem and
no "hacks" become needed scattered in various mojos doing version resolution.
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728880#comment-17728880
]
Tamas Cservenak commented on MNG-7802:
--
Ok, then just for the context: the local repo was "corrupted" in a way that
resolver was unable to find the lastUpdated timestamp in otherwise healthy
file, in these cases resolver uses timestamp = 1L (1 Jan 1970 + 1ms) to signal
this. Still, the effective update policy was "never", so even so "old" file did
not trigger metadata update, that resulted in no discovery of new versions
(reported as bug).
Reason why it did not find that last updated timestamp is most probably
following: Garret used old(er) release of maven-versions-plugin, then switched
to new(er) version of same plugin. The old(er) one uses old code and bits from
maven-compat (a la Maven2), while new version of plugin was switched over to
direct use of resolver. The maven-compat and resolver use same file but
different keys to store last updated timestamp (for me due unknown reasons, but
I guess is to keep their "update cadence" completely separated).
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728873#comment-17728873
]
Garret Wilson commented on MNG-7802:
I'll try to stay out of this discussion because I don't have time to dig into
the deep Maven code internals right now, but I wanted to clarify [something
said
above|https://issues.apache.org/jira/browse/MNG-7802?focusedCommentId=17728840&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17728840]
to put this into context:
{quote}As discovered during lengthy MRESOLVER-363 (and related
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){quote}
I disagree that my local repository was "corrupted". Maybe Maven Resolver
didn't understand it, but it wasn't corrupted. My
{{resolver-status.properties}} file was a completely valid properties file with
this content:
{code}
#Last modified on: Thu Sep 08 15:34:35 PDT 2022
#Thu Sep 08 15:34:35 PDT 2022
central.maven-metadata-central.xml.lastUpdated=1662676475074
{code}
The fact that Maven Resolver decided to interpret this as "Jan 1 1970" is a
decision Maven Resolver made. This file doesn't say "Jan 1 1970", it says
2022-09-08.
I was told that Maven Resolver recognizes a different property than
{{central.maven-metadata-central.xml.lastUpdated}}. Still nothing told Maven
Resolver "Jan 1 1970". Instead, Maven Resolver took it upon itself to say, "I
see that you wanted to indicate when you were updated, but I don't understand
it, so I'm never, ever going to update this file."
Additionally we have to ask where
{{central.maven-metadata-central.xml.lastUpdated}} came from in the first
place. Somebody in [Versions Maven Plugin
#959|https://github.com/mojohaus/versions/issues/959] said it might have come
from some [Maven Compatibility
Layer|https://maven.apache.org/ref/3.9.2/maven-compat/]. I haven't looked into
this to find out the details, but if Maven Resolver doesn't know how to work
with data from the Maven Compatibility Layer, then … shouldn't it? My point is
that there is no "corruption" here. Everything worked as normal based upon some
set of tools, and Maven Resolver just wasn't in the loop on what to expect with
what something else wrote.
You and I as humans can look at the file above and figure out what was
intended. There is zero ambiguity in the file about what the last updated
timestamp should be. The file is 100% machine processable. Shouldn't there be
some way to improve Maven Resolver to figure that out as well?
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728846#comment-17728846
]
Tamas Cservenak commented on MNG-7802:
--
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)
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728840#comment-17728840
]
Tamas Cservenak commented on MNG-7802:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy 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"
* "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
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728838#comment-17728838
]
ASF GitHub Bot commented on MNG-7802:
-
cstamas commented on PR #1144:
URL: https://github.com/apache/maven/pull/1144#issuecomment-1574131188
Looks good, but:
* the CLI `-U` should be changed (not snapshot update but all update, I mean
change the help text)
* as IT failures show, IF `-U` present, do what happened before (stick
ALWAYS to session), if not present, do partially what in PR
> 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)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728802#comment-17728802
]
ASF GitHub Bot commented on MNG-7802:
-
gnodet opened a new pull request, #1144:
URL: https://github.com/apache/maven/pull/1144
(no comment)
> 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{_}.
>
>
> Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect all policies, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
