[
https://issues.apache.org/jira/browse/MRESOLVER-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726644#comment-17726644
]
Garret Wilson commented on MRESOLVER-363:
-----------------------------------------
Good morning. There are two big things I don't understand about this behavior:
1.
Modern build systems has the beautiful concept of an immutable, repeatable
build. If an artifact is versioned, then once you have an artifact with a
version, you know that it's the latest, so there is no point in ever updating
it. In fact you _shouldn't_ (unless there was some error in the process, in
which case you can override it to fix the error). Everything I'm saying here
you already know and could recite in your sleep I'm sure.
But {{maven-metadata-central.xml}} is not a versioned artifact. It has no
version. We _know_ that we may update this artifact–in fact no only that we
"may" update the artifact, we know that _we probably will_ update this
artifact. The whole purpose of this artifact is to _track the changing state of
the server_. It is like {{HEAD}} in get. {{HEAD}} is not immutable. It simply
tells us whether we're in sync with the server or not. It is very closely
analogous to a {{-SNAPSHOT}} version. In fact it is a "shapshot" of the server.
_It is not a versioned artifact._
So why on earth would {{maven-metadata-central.xml}} have a policy of "never
update"? How could that ever be even close to correct? It's not versioned. It's
purpose is not to track some finalized state; it's purpose is rather to track
the synchronization state of _things that are always changing_. Could you
imagine putting a "never update" policy on Git {{HEAD}}? I'm not understanding
the reasoning here.
2.
Orthogonally, the current behavior is _not_ to update the metadata if
{{resolver-status.properties}} is missing (or does not have the expected "last
updated" information). This also doesn't make sense to me. When I am writing
software that synchronizes with a server, if the "last-updated" flag is
missing, the reasonable action to me is to synchronize (because we don't know
when it was last updated) and then update the "last-updated" flag so we'll know
in the future. I don't see any benefits to the approach of, "if we don't know
when we last updated, assume that we last updated recently".
In fact this approach is demonstrably incorrect, because if you wait long
enough, the behavior is guaranteed to be wrong. Assume that we only need to
update once every 1 year. If the "last-updated" flag is missing, the current
approach assumes that it has been updated less a year ago. And for a while that
will be correct. But eventually that will be wrong; eventually more than one
year will have past, so the assumption will be wrong. The point is that this
approach guarantees that _eventually the behavior will always be incorrect_.
Even if you only want to refresh after 100 years. Even if you put 1000 years.
If the software assumes that everything is up-to-date when the "last-updated"
flag is missing, then that approach _guarantees_ incorrect behavior eventually.
A better approach is to update the file and set the "last-updated" flag if the
"last-updated" flag is missing. This may at most result in a single "extra"
update, but that is benign, and going forward it will function correctly.
Taking the other approach _guarantees_ incorrect behavior forever, for hundreds
and thousands of years.
> Maven metadata is not updated in some cases
> -------------------------------------------
>
> Key: MRESOLVER-363
> URL: https://issues.apache.org/jira/browse/MRESOLVER-363
> Project: Maven Resolver
> Issue Type: Bug
> Affects Versions: 1.9.10
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
>
> Seems when update check for metadata happens, and:
> * maven-metadata XML is present, but
> * resolver-status.properties is not, OR was created by maven-compat, that
> uses different key for lastUpdated. Effectively the value of lastUpdated is
> not present.
> The update check falsely DO NOT check for update, as it will end up with
> update policy "never" in update policy analyzer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
