Howdy, That's interesting, but how came then into his debug logs the "Determining..." line that IS in maven-compat: https://github.com/apache/maven/blob/maven-3.9.2/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L76
T On Thu, May 25, 2023 at 2:46 PM Slawomir Jaranowski <s.jaranow...@gmail.com> wrote: > Hi, > > Short hint > > org.apache.maven.repository.RepositorySystem is not used for resolving by > versions plugin > It used > for repositorySystem.createPluginArtifact, > repositorySystem.createDependencyArtifact > > > https://github.com/mojohaus/versions/blob/master/versions-common/src/main/java/org/codehaus/mojo/versions/api/DefaultVersionsHelper.java > > > czw., 25 maj 2023 o 11:23 Tamás Cservenák <ta...@cservenak.net> > napisał(a): > > > 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 > > > > > > > > > > > -- > Sławomir Jaranowski >
