Good morning and thanks for such an interesting history of Maven
evolution, Tamás. See below on discussion for next troubleshooting steps:
On 5/25/2023 2:23 AM, Tamás Cservenák wrote:
…
I really cannot tell who or what (my guess) corrupted the "update
check" related files.
This is the part of the response that confuses me. What "'update check'
related files" are we talking about? I infer from the discussion that
nobody knows the "exact" file. But for the artifact
`com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`, aren't we
pretty sure that whatever is "corrupted" is in the
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin`
directory right? This is an honest question: is there any place else
that the Versions Maven Plugin stack could potentially be using to know
if it should check Maven central?
And if
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin`
is the only place that could be affecting this problem, well … there are
not a lot of files in that directory.
And now that we have a better idea of what Versions Maven Plugin is
really using to check for updates (and isn't as simple as we thought
before), doesn't the source code give us some idea about what files it
is checking? You mentioned m2e and the like, and sure, I understand that
they all potentially use different things and can potentially change
different files in different ways. But in Maven 3.9.1 when I execute
`mvn versions:display-plugin-updates`, I am not using m2e—I am only use
a single tool that we have the source code to and undoubtedly some of
you even wrote part of. And we have no idea what particular file the
current Versions Maven Plugin stack would be checking to see if the
cache is stale? That's the part I honestly am not understanding.
As it was said before, your best bet is to "nuke" your local
repository, as it is really just a cache and should be considered as such.
But what does that solve? That gets me past an issue that I have right
now, this morning. But what about tomorrow? How long will I know that my
brand new cache is up-to-date for? A day? A week? Next month, can I
trust Versions Maven Plugin? I have over 25,000 files in my
`~/.m2/repository`. When might one of the new ones get "stuck" again?
Should I create a script that blows away my `~/.m2/repository` every
morning when my computer boots up?
And here's the larger issue: this is not just about me. Think about all
the developers out there using Versions Maven Plugin. How many of them
are getting stale information and don't even know it? Should we add a
feature to Maven to blow away `~/.m2/repository` the first time it is
run ever 24 hours? That wasn't a serious suggestion; I'm just trying to
make a point: until we know how prevalent it is (which we won't know
until we know more about what exactly is happening), "nuking"
`~/.m2/repository` doesn't "solve" anything.
Now I'm happy to "nuke" my `~/.m2/repository` if I do it in a way that
gets us closer to understanding what the problem is here. As I mentioned
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin`
seriously does not _have_ a lot of files. And the files are pretty
simple—it shouldn't be hard to see if they are "corrupted". Let me go
through what I (just from looking at the files) would think would be
candidates for being the problem:
* `maven-metadata.xml`: This file is missing! The debug output says,
"Could not find metadata
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml
in local (C:\Users\user\.m2\repository)". And indeed this file is not
there. Could this be related?
* `resolver-status.properties`: This file contains a single line:
`central.maven-metadata-central.xml.lastUpdated=1662676475074`.
Interpreting the value as a Unix epoch-based timestamp, this indicates a
date of 2022-09-08, which matches the `Thu Sep 08 15:34:35 PDT 2022` in
the comments
* `maven-metadata-central.xml`: This file has `<latest>2.1.2</latest>`,
`<release>2.1.2</release>`, a list of versions ending in
`<version>2.1.2</version>`, and finally a
`<lastUpdated>20210818055556</lastUpdated>`. At first I interpreted this
date as a Unix epoch-based timestamp, which would indicate a date far
into the future. But an [answer on Stack
Overflow](https://stackoverflow.com/a/76303661) indicated my assumption
was incorrect—that this is instead a YYYYMMDD… type string timestamp,
indicating 2021-08-18. Oddly this date does not match the time in
`resolver-status.properties`. Even stranger, the file system timestamp
of `maven-metadata-central.xml` is 2022-09-08, which _does_ match the
date in `resolver-status.properties`, and in fact also matches the file
system timestamp of `maven-metadata-central.xml.sha1`!! It seems odd
that the checksum file for `maven-metadata-central.xml` would have a
file system timestamp of 2022-09-08, the `resolver-status.properties`
file would have a file system timestamp of 2022-09-08, the internal
value of `resolver-status.properties` would have a timestamp of
2022-09-08, yet the internal timestamp of `maven-metadata-central.xml`
would indicate 2021-08-18.
* `2.1.3/_remote.repositories`. This contains no timestamp value, but
has a comment indicating it was generated on 2022-10-24.
* `2.1.3/_m2e-lastUpdated.properties`: This has a single line
`central|https\://repo.maven.apache.org/maven2|null=1684861907880`.
Interpreting `1684861907880` as a Unix epoch-based timestamp yields
2023-05-23, which in fact matches the comment in the file indicating
when it was generated.
I can see no other files that are likely candidates for corruption. And
none of them look complicated. Surely it can't be that difficult to at
least narrow this down some.
Based upon nothing more than my gut instinct from years of software
development, my first thought is: would it be possible that the Versions
Maven Plugin stack is reading
`<lastUpdated>20210818055556</lastUpdated>` from
`maven-metadata-central.xml` and interpreting it as a Unix epoch-based
timestamp rather than a YYYYMMDD string (the mistake I made), and
thinking that this is a date in the future? Perhaps one of these other
legacy components Tamás described wrote a value based upon a different
assumption of what the field holds.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
