Howdy, So Garret, sorry for the long response, and exactly for its length I have to say in advance: this will NOT solve your problem :(
For readers: context https://github.com/mojohaus/versions/issues/959 OTOH, it sheds some light on the "passive aggressive" stance of some Maven Core developers (me for example), but for this a short history lesson is needed. There was Maven2 (rewrite of Maven1, so no "history" in there), and then Maven3 happened. Biggest change in Maven3 was the introduction of Resolver (Mercury, Sonatype Aether, Eclipse Aether, today Maven Resolver), as Maven2 had "resolving" code scattered all over the place, duplicated, and causing bugs and maintenance problems. One of the major goals of Maven3 was to promise "smooth sailing" for Maven2 users, so full backward compatibility was the goal as well. This is one of the reasons why the maven-compat module exists today, it contains Maven2 "compatibility layer" (alternate implementations from Maven2 times), for plugins that still use Maven2 codebase. On the other hand, this "smooth sailing" for users introduced quite challenging (technical) issues below the surface for devs. This is complicated by the fact that neither Maven2 nor Maven3 had no "well defined API" per se, as it was really just "a bunch of classes and components". In reality, a very tiny subset of plugins can afford to depend on maven-plugin-api ONLY. They usually need more, and depend on maven-core (the implementation), maven-compat (maven2 compat layer), maven-whatever. Most Maven could do is somehow "signal" the intent to developers in javadoc or package naming (ie. by placing class into "internal" Java package denoting "this is private, please do not touch", example of this can be seen here https://maven.apache.org/resolver/api-compatibility.html). For example, what Maven3 was fighting with sword and fire (very eagerly) was to achieve, that code reaching to local or remote repo does not do this: https://github.com/apache/maven-verifier/blob/maven-verifier-1.8.0/src/main/java/org/apache/maven/it/Verifier.java#L577 Similar code was scattered (copy pasted) all across the Maven2 and Maven2 plugin codebase. Instead, it required devs to use resolver APIs (and leave layout hidden): https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-api/src/main/java/org/eclipse/aether/repository/LocalRepositoryManager.java Related problem is reaching out to plugin developers. For some reason (historically I guess, and it simply got into people's reflex), plugins are usually compiled against the same version of Maven artifacts as the plugin declared as "maven prerequisite", the minimal supported Maven version by plugin. For ASF Maven plugins that is 3.2.5. Hence, they compile against maven-core 3.2.5, maven-compat 3.2.5 etc (in case of ASF plugins). The 3.2.5 version was released in 2014. Therefore, whatever we deprecate in Maven 3.8.x, 3.9.x etc goes unnoticed by plugin devs, as they compile against classes from 2014, there is no deprecations shown in IDEs or during compilation. At the same time, at runtime with latest Maven versions, we must provide binary compatibility, as the Maven "swaps out" plugin declared maven-core 3.2.5 with current maven-core 3.9.2 or so. So this begs the question, "what makes a plugin 2.x or 3.x"? From that above, one may simply say "a plugin that requires maven-compat at runtime (uses components or code from) is 2.x plugin". So, for plugins requiring maven-compat at build time (ie. compile scope), answer is trivial: is 2.x plugin. Things get a bit more complicated, as almost all otherwise 3.x plugins require maven-compat in test scope, but this is more "technical issue", the test framework in use requires it (it relies on maven-compat, while the plugin tested may not). So, maven-compat in the test scope could be fine. And finally, we arrive to Garret's case: it turns out we have a cuckoo egg in maven-core (not that it was "secret", but I got really surprised when dug myself into what is happening here): The maven-core org.apache.maven.repository.RepositorySystem component. Sadly, it's name is SAME to Resolver RepositorySystem, but that's not the only problem with this component. The problem lies in fact that maven-core contains the component interface, while the implementation for this component is in maven-compat org.apache.maven.repository.legacy.LegacyRepositorySystem and from this moment on, we delve into Maven2 compatibility layer that exists in parallel with Maven Resolver (this is "salvaged" Maven2 code, doing or redoing mostly same what Maven Resolver does). Simply put, this seemingly valid component org.apache.maven.repository.RepositorySystem keeps wide open gates leading to the rabbit hole of Maven2 codebase that lives in parallel with Maven3. Most revealing were Garret debug messages "[DEBUG] Determining update check for artifact" that Andrzej and I myself were wrong when we both stated "it comes from resolver". It does not, it comes from here: https://github.com/apache/maven/blob/maven-3.9.2/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L76 Now, this "update check manager" coexists and works totally independently from resolver related classes. they are literally "doing the same thing differently" and work against same local repository: https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManager.java https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.10/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java Consequence: maven plugin using org.apache.maven.repository.RepositorySystem component is a Maven2 plugin. Hence, the conclusion is: * versions-maven-plugin uses org.apache.maven.repository.RepositorySystem quite extensively (and debug logs contains logs from maven-compat), it is Maven2 plugin * org.apache.maven.repository.RepositorySystem uses Maven2 classes to reach out to local and remote repository * transport is cast in steel: users of this component are married to Wagon (see WagonManager in LegacyRepositorySystem implementation) * OTOHm resolver local repository format did receive some (mild) changes since Maven 3.0 * but, I guess these "Maven2 compat" classes were "frozen" (read: unchanged) since * I assume total breakage if some advanced resolver feature is used like "split repository", like https://issues.apache.org/jira/browse/MNG-7663 (could be tested) Consequences for plugins using org.apache.maven.repository.RepositorySystem: * whatever new transport (HTTP/2 or whatever) is introduced by resolver, they will stick with legacy Maven2 Wagon * whatever new local repository feature is introduced (or used at runtime!) by users, they will be unaware of it (or even break with it) * "shared repo" feature (locking) is what comes to my mind, seems completely circumvented by legacy code, and may explain some issues users reported Disclaimer: all this by just skimming sources, I may be wrong at several points! === As for me, what I will do instead, is to add yet-another passive aggressive warning for plugins injecting this legacy component :) (that will be missed by plugin developers, as by overwhelming requests, the upcoming Maven 3.9.3 will have these kinds of validation warnings "toned down", not displayed by default) Also created https://issues.apache.org/jira/browse/MNG-7794 On parallel note, seems we will not be able to achieve this: https://gist.github.com/cstamas/b0605a9fad09de4adcbd4444888baa4c As many Maven3 plugins MAY be actually Maven2 plugins without knowing it, hence for Maven4 to support Maven3 plugins will still be needed to drag Maven2 codebase :( For me, this issue is an exact picture of the problem Maven project is struggling with. The Maven ecosystem cannot be fixed ONLY by Maven devs. === So, Garret, given your local repository is accessed by: * local repository holds a "state" * is modified by maven core (does NOT use maven-compat) that uses resolver * is modified by maven plugins, that may use maven-compat that use "maven2 compat", like in your case * is modified by m2e (I guess uses resolver, but again, as complete maven core is present in it, am unsure) I really cannot tell who or what (my guess) corrupted the "update check" related files. 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. HTH T On Thu, May 25, 2023 at 9:01 AM Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > Hi, > > as I wrote on SO... are you in a corporate environment and using a > repository manager ? > > Kind regards > Karl Heinz Marbaise > On 24.05.23 18:04, Garret Wilson wrote: > > I'm writing to this list on the advice of Andrzej Jarmoniuk on [Versions > > Maven Plugin Issue > > #959](https://github.com/mojohaus/versions/issues/959). I have also > > opened a [Stack Overflow question](https://stackoverflow.com/q/76307809) > > with a bounty, but so far there have been no responses. > > > > In short Maven Artifact Resolver on my machine seems to be stuck at some > > previous point in time; it does not see the latest versions on Maven > > Central when I am requested updated plugin versions using Versions Maven > > Plugin. It shows that there are newer versions available, but the ones > > it shows are not the latest available. Before deleting my entire > > `C:\Users\user\.m2\repository\` directory tree I would prefer to know > > what is caused this scenario so that it won't happen again in the > > future. But at the moment I don't even understand what condition (e.g. > > incorrect timestamps or whatever) is currently causing this behavior. > > > > I am using Maven 3.9.1 on Windows 10. I also use Eclipse EE 2023-03, > > which contains m2e (Eclipse's support for Maven). I start with [this > > `pom.xml`]( > https://github.com/globalmentor/globalmentor-root/blob/bce5bdbac7797b5b9114a72e5da2f4d76f3e24a7/pom.xml), > which uses `org.codehaus.mojo:versions-maven-plugin:2.12.0`, which in turn > (I am told) uses Maven Artifact Resolver. (Note that I've tried the latest > `org.codehaus.mojo:versions-maven-plugin:2.15.0` as well, with the same > results. I'm using this POM because it's available online and does not > contain any version ignores to cause confusion.) > > > > I wanted to see what plugins were out of date, so I ran: > > > > ```bash > > mvn versions:display-plugin-updates > > ``` > > > > It shows this: > > > > ``` > > [INFO] The following plugin updates are available: > > [INFO] maven-failsafe-plugin .......................... 2.22.2 -> > > 3.0.0-M7 > > [INFO] maven-release-plugin ............................ 2.5.3 -> > > 3.0.0-M6 > > [INFO] maven-site-plugin .............................. 3.12.1 -> > > 4.0.0-M3 > > [INFO] maven-surefire-plugin .......................... 2.22.2 -> > > 3.0.0-M7 > > [INFO] org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> > > 3.0.5 > > ``` > > > > However in Versions Maven Plugin Issue #959 (see link above), Andrzej > > Jarmoniuk ran the same command and came up with different answers. Here > > are two examples: > > > > ``` > > [INFO] org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> > > 3.1.0 > > ``` > > > > Note that my output is only showing v3.0.5 is available for > > `org.springframework.boot:spring-boot-maven-plugin`. Furthermore there > > are later versions available for some of the other plugins as well. > > > > ``` > > [INFO] com.akathist.maven.plugins.launch4j:launch4j-maven-plugin 2.1.3 > > -> 2.4.1 > > ``` > > > > My output doesn't even show > > `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`; apparently > > it thinks thje v2.1.3 listed in the POM is the latest available! > > > > It would appear that Maven Artifact Resolver is somehow "stuck" at some > > earlier point in time on my machine. > > > > I ran Maven with the `-X` option, and here is part of the output related > > to `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`: > > > > ``` > > … > > [DEBUG] Checking > > com.akathist.maven.plugins.launch4j:launch4j-maven-plugin for updates > > newer than 2.1.3 > > [DEBUG] Could not find metadata > > > com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml > in local (C:\Users\user\.m2\repository) > > [DEBUG] Skipped remote request for > > > com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, > locally cached metadata up-to-date > > [DEBUG] > > [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].version=2.1.3 > > [DEBUG] > > > [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].artifactVersion=2.1.2 > > [DEBUG] > > > [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].effectiveVersion=2.1.3 > > [DEBUG] > > > [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].specified=true > > … > > ``` > > > > This debug information seems to be saying that it can't find > > > `C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata.xml`. > And in fact that file does not exist! Instead I have > `C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata-central.xml`. > (I don't know what the differences are.) > > > > The more ominous line is this one: > > > > > `[DEBUG] Skipped remote request for > > > com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, > locally cached metadata up-to-date` > > > > What might be causing Maven Resolver on my machine to get "stuck" at an > > earlier point in time, and/or to skip checking Maven Central altogether > > for newer versions of many plugins? > > > > Garret Wilson > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
