[
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)
