Versions Maven Plugin not showing latest plugins available with ignores.

[garretwilson]

On Windows 10 with Maven 3.9.1 I upgraded to org.codehaus.mojo:versions-maven-plugin:2.15.0.

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>versions-maven-plugin</artifactId>
  <version>2.15.0</version>
</plugin>

I wanted to see what plugins were out of date, so I ran:

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

So I added ignores for milestone releases as discussed in #684 and originally in #258:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>versions-maven-plugin</artifactId>
  <version>2.15.0</version>
  <configuration>
    <ruleSet>
      <ignoreVersions>
        <ignoreVersion><type>regex</type><version>.*-SNAPSHOT</version></ignoreVersion>
        <ignoreVersion><type>regex</type><version>.*-alpha(?:-?\d+)?</version></ignoreVersion>
        <ignoreVersion><type>regex</type><version>.*-beta(?:-?\d+)?</version></ignoreVersion>
        <ignoreVersion><type>regex</type><version>.*-M(?:-?\d+)?</version></ignoreVersion>
        <ignoreVersion><type>regex</type><version>.*-RC(?:-?\d+)?</version></ignoreVersion>
        <ignoreVersion><type>regex</type><version>.*-pfd(?:-?\d+)?</version></ignoreVersion>
      </ignoreVersions>
    </ruleSet>
  </configuration>
</plugin>

Now when I run mvn versions:display-plugin-updates it gives me:

[INFO] No plugins require a newer version of Maven than specified by the pom.

This is wrong on several counts. org.apache.maven.plugins:maven-failsafe-plugin for example has v3.0.0 and 3.1.0 available—two versions released after the current version.

And the bug apparently has nothing to do with ignoring the *-M* versions, because it even skipped Spring Boot Maven Plugin, which is currently at v3.1.0.

This would appear critically broken, in that it does not show new versions, which is the essential function of this goal.

Or did I get the regular expressions wrong somehow? (I think they can be simplified a bit; I was starting from those in a Stack Overflow answer. But in any case I don't see how these regular expressions would be hiding versions in the form 3.0.5.)

[andrzejj0]

Can't reproduce.

Using version 2.15.0 with a minimal pom.xml with the failsafe plugin and the rule set you provided:

<build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>versions-maven-plugin</artifactId>
        <version>2.15.0</version>
        <executions>
          <execution>
            <id>run</id>
            <phase>validate</phase>
            <goals>
              <goal>display-plugin-updates</goal>
            </goals>
            <configuration>
              <ruleSet>
                <ignoreVersions>
                  <ignoreVersion><type>regex</type><version>.*-SNAPSHOT</version></ignoreVersion>
                  <ignoreVersion><type>regex</type><version>.*-alpha(?:-?\d+)?</version></ignoreVersion>
                  <ignoreVersion><type>regex</type><version>.*-beta(?:-?\d+)?</version></ignoreVersion>
                  <ignoreVersion><type>regex</type><version>.*-M(?:-?\d+)?</version></ignoreVersion>
                  <ignoreVersion><type>regex</type><version>.*-RC(?:-?\d+)?</version></ignoreVersion>
                  <ignoreVersion><type>regex</type><version>.*-pfd(?:-?\d+)?</version></ignoreVersion>
                </ignoreVersions>
              </ruleSet>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
        <version>2.22.2</version>
      </plugin>
    </plugins>
  </build>

[DEBUG] Version 3.0.0-M1 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M2 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M3 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M4 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M5 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M6 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M7 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M8 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] Version 3.0.0-M9 for artifact org.apache.maven.plugins:maven-failsafe-plugin found on ignore list: .*-M(?:-?\d+)? (regex)
[DEBUG] [org.apache.maven.plugins:maven-failsafe-plugin].version=2.22.2
[DEBUG] [org.apache.maven.plugins:maven-failsafe-plugin].artifactVersion=3.1.0
[DEBUG] [org.apache.maven.plugins:maven-failsafe-plugin].effectiveVersion=2.22.2
[DEBUG] [org.apache.maven.plugins:maven-failsafe-plugin].specified=true
[DEBUG] Checking org.codehaus.mojo:versions-maven-plugin for updates newer than 2.15.0
[DEBUG] Found ignored versions: .*-SNAPSHOT (regex), .*-alpha(?:-?\d+)? (regex), .*-beta(?:-?\d+)? (regex), .*-M(?:-?\d+)? (regex), .*-RC(?:-?\d+)? (regex), .*-pfd(?:-?\d+)? (regex)

and further:

[DEBUG] [org.codehaus.mojo:versions-maven-plugin].version=2.15.0
[DEBUG] [org.codehaus.mojo:versions-maven-plugin].artifactVersion=2.15.0
[DEBUG] [org.codehaus.mojo:versions-maven-plugin].effectiveVersion=2.15.0
[DEBUG] [org.codehaus.mojo:versions-maven-plugin].specified=true
[INFO] 
[INFO] The following plugin updates are available:
[INFO]   maven-failsafe-plugin ............................. 2.22.2 -> 3.1.0
[INFO] 
[INFO] All plugins have a version specified.
[INFO] 
[DEBUG] MinimalMavenBuildVersionFinder: No maven-enforcer-plugin used
[WARNING] Project does not define minimum Maven version required for build, default is: 3.2.5
[INFO] Plugins require minimum Maven version of: 3.2.5

So, feel free to provide a pom.xml or a debug log or anything that would help reproduce this.

[garretwilson]

So, feel free to provide a pom.xml or a debug log or anything that would help reproducing this.

Sure. Use this pom.xml. It's the exact POM I'm using except that I had advanced the overall POM version to the next -SNAPSHOT version (which should have no influence on this issue).

[andrzejj0]

Otherwise, you're free to contribute.

[andrzejj0]

Without any rules, it will show upgrades to 3.1.0 etc.

  globalmentor-root git:(main) mvn org.codehaus.mojo:versions-maven-plugin:2.15.0:display-plugin-updates

will give

[INFO] Scanning for projects...
[INFO] Inspecting build with total of 1 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 1 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO] 
[INFO] -----------------< com.globalmentor:globalmentor-root >-----------------
[INFO] Building GlobalMentor Root 0.8.15
[INFO]   from pom.xml
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- versions:2.15.0:display-plugin-updates (default-cli) @ globalmentor-root ---
[INFO] 
[INFO] The following plugin updates are available:
[INFO]   com.akathist.maven.plugins.launch4j:launch4j-maven-plugin  2.1.3 -> 2.4.1
[INFO]   maven-assembly-plugin .............................. 3.4.2 -> 3.6.0
[INFO]   maven-compiler-plugin ............................ 3.10.1 -> 3.11.0
[INFO]   maven-dependency-plugin ............................ 3.3.0 -> 3.5.0
[INFO]   maven-deploy-plugin ................................ 3.0.0 -> 3.1.1
[INFO]   maven-enforcer-plugin .............................. 3.1.0 -> 3.3.0
[INFO]   maven-failsafe-plugin ............................. 2.22.2 -> 3.1.0
[INFO]   maven-install-plugin ............................... 3.0.1 -> 3.1.1
[INFO]   maven-jar-plugin ................................... 3.2.2 -> 3.3.0
[INFO]   maven-release-plugin ............................... 2.5.3 -> 3.0.0
[INFO]   maven-resources-plugin ............................. 3.3.0 -> 3.3.1
[INFO]   maven-site-plugin .............................. 3.12.1 -> 4.0.0-M8
[INFO]   maven-surefire-plugin ............................. 2.22.2 -> 3.1.0
[INFO]   org.codehaus.mojo:build-helper-maven-plugin ........ 3.3.0 -> 3.4.0
[INFO]   org.codehaus.mojo:versions-maven-plugin .......... 2.12.0 -> 2.15.0
[INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> 3.1.0
[INFO] 
[INFO] All plugins have a version specified.
[INFO] 
[INFO] Project requires minimum Maven version for build of: 3.5.0
[INFO] Plugins require minimum Maven version of: 3.2.5
[INFO] 
[INFO] No plugins require a newer version of Maven than specified by the pom.
[INFO] 
[INFO] Require Maven 3.6.3 to use the following plugin updates:
[INFO]   maven-help-plugin .................................. 3.3.0 -> 3.4.0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  4.787 s
[INFO] Finished at: 2023-05-20T19:28:09+02:00
[INFO] ------------------------------------------------------------------------

[garretwilson]

You also mentioned:

        <executions>
          <execution>
            <id>run</id>
            <phase>validate</phase>
            <goals>
              <goal>display-plugin-updates</goal>
            </goals>

Just a note: this may or may not make a difference, but please note that in my report I am not tying check to any lifecycle. I am invoking it from the command line. (This is essential for my use case.)

You should be able to simply take the POM I linked to and run the Bash/PowerShell command I mentioned. Then add the exact configuration I provided to the POM with no further changes.

[garretwilson]

Without any rules, it will show upgrades to 3.1.0 etc.

Yes. 👍

The whole point of of this ticket is that by adding ignore rules for e.g. milestones, it will also, incorrectly and erroneously, ignore valid, non-ignored versions.

[andrzejj0]

Well, the phase is there so that I can then invoke it using validate. This does not influence anything.

Please read the output of the command line invocation above.

And with a set of ignored versions:

mvn org.codehaus.mojo:versions-maven-plugin:2.15.0:display-plugin-updates -Dmaven.version.ignore=1\.0\.1,.+-M.

[INFO] --- versions:2.15.0:display-plugin-updates (default-cli) @ globalmentor-root ---
[INFO] 
[INFO] The following plugin updates are available:
[INFO]   com.akathist.maven.plugins.launch4j:launch4j-maven-plugin  2.1.3 -> 2.4.1
[INFO]   maven-assembly-plugin .............................. 3.4.2 -> 3.6.0
[INFO]   maven-compiler-plugin ............................ 3.10.1 -> 3.11.0
[INFO]   maven-dependency-plugin ............................ 3.3.0 -> 3.5.0
[INFO]   maven-deploy-plugin ................................ 3.0.0 -> 3.1.1
[INFO]   maven-enforcer-plugin .............................. 3.1.0 -> 3.3.0
[INFO]   maven-failsafe-plugin ............................. 2.22.2 -> 3.1.0
[INFO]   maven-install-plugin ............................... 3.0.1 -> 3.1.1
[INFO]   maven-jar-plugin ................................... 3.2.2 -> 3.3.0
[INFO]   maven-release-plugin ............................... 2.5.3 -> 3.0.0
[INFO]   maven-resources-plugin ............................. 3.3.0 -> 3.3.1
[INFO]   maven-surefire-plugin ............................. 2.22.2 -> 3.1.0
[INFO]   org.codehaus.mojo:build-helper-maven-plugin ........ 3.3.0 -> 3.4.0
[INFO]   org.codehaus.mojo:versions-maven-plugin .......... 2.12.0 -> 2.15.0
[INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> 3.1.0
[INFO] 
[INFO] All plugins have a version specified.
[INFO] 
[INFO] Project requires minimum Maven version for build of: 3.5.0
[INFO] Plugins require minimum Maven version of: 3.2.5
[INFO] 
[INFO] No plugins require a newer version of Maven than specified by the pom.
[INFO] 
[INFO] Require Maven 3.6.3 to use the following plugin updates:
[INFO]   maven-help-plugin .................................. 3.3.0 -> 3.4.0

[garretwilson]

Oh, @ajarmoniuk , could it be that I looked at the wrong section of my output? (It was several screens-ful.)

I saw:

[INFO] No plugins require a newer version of Maven than specified by the pom.

But now I see that this is saying that no plugins require a newer version of Maven, not that no plugins have updates.

It may be that I didn't see the list scrolled up above it.

I'm late for a meeting right now, but give me two or three hours and I'll double-check this. I appreciate your quick reply. It's possible that this is my mistake, looking at the wrong output. I'll reply back after my meeting.

[garretwilson]

@ajarmoniuk I was hoping that I had just made a mistake and looked at the wrong section of the output. Unfortunately I'm still seeing what I initially reported in this ticket, and I cannot reproduce the output you have.

Here is the exact POM I am testing against:

https://bitbucket.org/globalmentor/globalmentor-root/src/04937a60d6278f781840d510ce929e1a2a82c560/pom.xml?at=issues%2FJAVA-241

Please note that I am using Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8).

Here is the exact command I'm running, using Git for Windows Bash (or with PowerShell):

mvn versions:display-plugin-updates

Here is my output:

[INFO] Scanning for projects...
[INFO] Inspecting build with total of 1 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 1 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO]
[INFO] -----------------< com.globalmentor:globalmentor-root >-----------------
[INFO] Building GlobalMentor Root 0.8.16-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- versions:2.15.0:display-plugin-updates (default-cli) @ globalmentor-root ---
[INFO]
[INFO] The following plugin updates are available:
[INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> 3.0.5
[INFO]
[INFO] All plugins have a version specified.
[INFO]
[INFO] Project requires minimum Maven version for build of: 3.5.0
[INFO] Plugins require minimum Maven version of: 3.2.5
[INFO]
[INFO] No plugins require a newer version of Maven than specified by the pom.
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
…

Here is the only plugin it says needs updating:

[INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 -> 3.0.5

But something stranger is going on. You'll note that in your output, it shows that the latest version for org.springframework.boot:spring-boot-maven-plugin is v3.1.0, which is correct. But for me it is showing v3.0.5, whether nor not I add ignoreVersion to the configuration!

In addition I see that your output includes things like com.akathist.maven.plugins.launch4j:launch4j-maven-plugin 2.1.3 -> 2.4.1 which is correct, but I don't see that output whether I have ignoreVersion added or not.

It's as if my machine is stuck connected to an old version of Maven Central. It's unclear whether this is a plugin bug; it seems to be related to what information my machine is getting from Maven Central. Can you help me with any hints of what might be happening?

[garretwilson]

@ajarmoniuk , where does the Version Maven Plugin get its information from, and how does it cache the results? Does it rely on some version in Maven's cache? Does it keep its own cache? Does it always query the information each time, bypassing any cache?

[garretwilson]

I tried running this with Maven 3.9.2. Maven tells me there are validation problems with org.codehaus.mojo:versions-maven-plugin:2.15.0. I run with -Dmaven.plugin.validation=VERBOSE, and it tells me:

[WARNING] Plugin validation issues were detected in 1 plugin(s)
[WARNING]
[WARNING]  * org.codehaus.mojo:versions-maven-plugin:2.15.0
[WARNING]   Declared at location(s):
[WARNING]    * unknown
[WARNING]   Used in module(s):
[WARNING]    * com.globalmentor:globalmentor-root:0.8.16-SNAPSHOT (pom.xml)
[WARNING]   Plugin issue(s):
[WARNING]    * Plugin depends on plexus-container-default, which is EOL

It also tells me:

If no upgrade available, please notify plugin maintainers about reported issues.

I'll check to see if there is a separate issue for that already. I hope I don't get a warning each time I use the plugin after upgrading to Maven 3.9.2. But for this current issue, I wonder if using this end-of-life plexus-container-default plugin could have anything to do with the latest versions not showing up when running on my machine? (I don't know that it does—I'm just asking. I'm trying to find out what's causes this, and so far there are few leads.)

In any case, Maven 3.9.2 gives me the same outdated output.

[garretwilson]

@ajarmoniuk your output had DEBUG in it, which gave me an idea: I ran Maven with the -X option, and here is part of my result:

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

As I mentioned above, your output includes com.akathist.maven.plugins.launch4j:launch4j-maven-plugin 2.1.3 -> 2.4.1, while mine does not. So Maven wasn't seeing that com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:2.1.3 needed updating. 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 wonder what the difference is? I can't really find information about this online.

But 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

Why does it think that the local metadata is up-to-date? As mentioned there is no C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata.xml file, so I don't know what it's talking about. However the maven-metadata-central.xml file contains <lastUpdated>20210818055556</lastUpdated>, and https://www.epochconverter.com/ tells me that this date is… Saturday, June 16, 2610 12:07:35.556 PM! 😮

Oh, my … what has screwed up the timestamps in my local Maven repository? Could it have been a plugin? Or Eclipse m2e? (I'm using Eclipse EE 2023-03.)

There are several confusing things for C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\:

• The checksum in maven-metadata-central.xml.sha1 matches the SHA-1 hash of maven-metadata-central.xml. But the file timestamp on maven-metadata-central.xml is almost a month later (2022-10-02) than that of maven-metadata-central.xml.sha1 (2022-09-08).
• The <lastUpdated>20210818055556</lastUpdated> inside maven-metadata-central.xml, as mentioned above, indicates 2610-06-16.
• The resolver-status.properties file timestamp is identical to that of maven-metadata-central.xml.sha1, so they were apparently modified at the same time. The comments inside resolver-status.properties also say it was modified on 2022-09-08, and the central.maven-metadata-central.xml.lastUpdated=1662676475074 inside the file also seems to say that Maven Central was checked on that date.

OK, now here is something interesting. On 2022-09-08 is when I released v0.8.10 of this POM to Maven Central. As part of doing that:

• mvn versions:use-releases -DprocessParent -DgenerateBackupPoms=false was used to switch to the latest released versions.
• mvn versions:set -DremoveSnapshot -DgenerateBackupPoms=false was used to drop the -SNAPSHOT version from the project.
• mvn versions:display-dependency-updates was used to list any outdated dependencies to make sure they are up-to-date before final release.

Since the checksum of maven-metadata-central.xml matches that in maven-metadata-central.xml.sha1, which was updated on 2022-09-08, it seems likely that the incorrect <lastUpdated>20210818055556</lastUpdated> was set on 2022-09-08. Have you heard of versions:use-releases, versions:set, or versions:display-dependency-updates ever setting a <lastUpdated> in the future? Does it update the metadata in the local repository itself, or does it rely on Maven to do this? (Eclipse m2e is also a potential culprit.)

[andrzejj0]

Hi, could you please share the whole obfuscated debug log somewhere?

The feature has been quite thoroughly tested but there are always loose ends. So maybe we're onto something.

I'm suspecting that there's something fishy about the regular expressions. Not that yours are wrong but the shell you're using might not passing them correctly to Maven.

Re your questions - the plugin does not do things like dependency resolution etc., or retrieving dependencies from a remote repository or from the local repository ("Maven cache") on itself. It relies on Maven or its components to do that.

Dependency resolution is done using https://maven.apache.org/resolver/, retrieving or writing to cache is core Maven.

Since the checksum of maven-metadata-central.xml matches that in maven-metadata-central.xml.sha1, which was updated on 2022-09-08, it seems likely that the incorrect 20210818055556 was set on 2022-09-08. Have you heard of versions:use-releases, versions:set, or versions:display-dependency-updates ever setting a in the future? Does it update the metadata in the local repository itself, or does it rely on Maven to do this? (Eclipse m2e is also a potential culprit.)

Try using -U

https://stackoverflow.com/questions/26224842/how-exactly-mvn-u-works

And once again, perhaps it would be faster to just read the code and get to know how the plugin works under the hood. There you could create an integration test testing the very case you're experiencing and you could debug it. Also, faster, because of time difference at the least.

[garretwilson]

I'm suspecting that there's something fishy about the regular expressions. Not that yours are wrong but the shell you're using might not passing them correctly to Maven.

They aren't my regular expressions exactly; I modified them from an answer on Stack Overflow. I intended to simplify them a bit once this was working.

But in any case, do you think the regular expressions are even relevant anymore? It's not seeing that com.akathist.maven.plugins.launch4j:launch4j-maven-plugin needs updating even if I take the whole regular expressions ignore configuration out of the POM! It seems reasonable to me that the problem here is not the Versions Maven Plugin regular expression testing, but rather the bad lastUpdated data inside maven-metadata-central.xml in my local repository, telling Maven not to query Maven Central for new versions. Thus Versions Maven Plugin doesn't even know there are new versions available.

Try using -U

Right, that seems to be like the workaround I'll need to use in order to get this to work.

But it worries me that these timestamps were wrong to begin with, and I would really like to figure out what caused them before I simply force all them to be updated.

[andrzejj0]

Regarding Maven warnings in 3.9.2 -- yeah that's a kinda passive-aggressive way of Maven devs' of getting users to chase plugin maintainers to fix their dependencies. The one in versions-maven-plugin has already been done and will be fixed 2.16.0. Plenty of other plugins will still suffer from this and it will cause people relying on warnings from their CI/CD some hassle.

[garretwilson]

Dependency resolution is done using https://maven.apache.org/resolver/, retrieving or writing to cache is core Maven.

Good to know, thanks. So Maven Resolver is what should be updating those lastUpdated timestamps in maven-metadata-central.xml you think?

I note that Maven recently updated Resolver in MNG-7753 and MNG-7769. These supposedly fixed MRESOLVER-352 and MRESOLVER-357. I don't see anything in the tickets regarding corrupted lastUpdated timestamps, but I wonder if it's possible that there was a Maven Resolver bug that did this at some point?

I just had to go on and just cross my fingers it won't happen again without knowing what caused it, because at any time there could be new versions and I wouldn't know it if whatever did this did it again.

[andrzejj0]

But in any case, do you think the regular expressions are even relevant anymore?

But you said the issue is not occurring if you skip those ignored versions along with their regexes entirely. Or did I get that wrong?

[garretwilson]

But you said the issue is not occurring if you skip those ignored versions along with their regexes entirely. Or did I get that wrong?

I'm not sure what you mean when you say "skip those ignored versions".

If I check for updates on the latest pom.xml, it shows what I put in the description. That's without even adding the ignores (or any extra configuration). You'll note that it's missing com.akathist.maven.plugins.launch4j:launch4j-maven-plugin altogether, and that the latest version for org.springframework.boot:spring-boot-maven-plugin is out of date. I didn't even realize that this was incorrect until I looked more closely at the output you gave.

Adding the regular expression configuration only removes the -M* versions from the output. Thus it would seem that the ignore-versions part is working correctly based upon the versions Maven Resolver is passing back; the problem is that Maven Resolver isn't even checking for new versions, because a lot of things in my local repository have lastUpdated timestamps (way) in the future.

Did I explain it better that time? Does it make sense?

[andrzejj0]

Good to know, thanks. So Maven Resolver is what should be updating those lastUpdated timestamps in maven-metadata-central.xml you think?

I note that Maven recently updated Resolver in MNG-7753 and MNG-7769. These supposedly fixed MRESOLVER-352 and MRESOLVER-357. I don't see anything in the tickets regarding corrupted lastUpdated timestamps, but I wonder if it's possible that there was a Maven Resolver bug that did this at some point?

Oh one more thing. The plugin will use the version of Maven (and its libraries) that you're using to run it with. So, to bump them, you need to use a never version of Maven.

Also, if you clone this repository, you will be able to add your test case as an integration test. E.g. somewhere in there

you can then run it using maven invoker, e.g.

mvn -P run-its -Dmaven.invoker=<your-test-name>

or rely on the Github Actions flows to do it for you -- there you can add multiple platforms (Windows, MacOS, Linux) to test it on.

[garretwilson]

Oh one more thing. The plugin will use the version of Maven (and its libraries) that you're using to run it with. So, to bump them, you need to use a never version of Maven.

Right. I'm using Maven 3.9.1 right now.

At this point I'm just trying to find out what caused the bad timestamps—that's why I was looking at the Maven changelog to see if any Maven Resolver bugs had been fixed that said anything about bad timestamps.

[andrzejj0]

Maybe there indeed might be something wrong with Maven itself. Another thing you could do is remove the directory from the local Maven repo and see if that helps. It usually does for me.

[garretwilson]

Another thing you could do is remove the directory from the local Maven repo and see if that helps. It usually does for me.

Well, yes, I have no doubt that simply blowing away ~/.m2/repository will "solve" the problem because Maven won't see any last-updated timestamp and assume it needs to talk to Maven Central to get the latest versions. As you mentioned -U will be a more elegant way to do this.

But my my desire right now is that I'd like to know that caused this in the first place, rather that just "force-fixing" it and thinking, "oh, it was a fluke, it will never happen again".

[andrzejj0]

Does it get resolved properly if you use mvn dependency:get -Dartifact=... ?

https://maven.apache.org/plugins/maven-dependency-plugin/get-mojo.html

[garretwilson]

Does it get resolved properly if you use mvn dependency:get -Dartifact=... ?

You mean and specify an actual version? (I glanced at the docs and it looks like that's required.)

I'll have to try it tomorrow. It's best not to work when my mind is tired after a long, busy day. Thanks for the input. I'll investigate more after some rest.

[garretwilson]

Good morning. I opened Maven lastUpdated timestamps in maven-metadata.xml have been set to the future to try to find out how/why this happened.

[garretwilson]

@ajarmoniuk they pointed out on Stack Overflow that those <lastUpdated>20210818055556</lastUpdated> timestamps I was seeing are not Unix epoch numbers but YYYYMMDD… values. Thus the values are note set in the future. So I'm back to square one and still don't know why your machine is seeing certain new plugins available from Maven Central but mine is not, even with the exact same POM.

[andrzejj0]

Frankly, I'm not so sure why this might occur. However, this is not this plugin but rather Maven (and, possibly, Resolver). Might be caused by a corrupted local repository. How can it get corrupted is not clear to me, "a network glitch" in the Baeldung article hints to some problems with cleanup while releasing resources faced with network errors.

https://www.baeldung.com/maven-force-update contains some hints on how to deal with this

Does this only happen with plugins or also with dependencies (with dependencies that would mean that a dependency with the given version, which does exist in the central repo, can't be downloaded)?

Another idea is to look for/create a new issue on https://issues.apache.org/jira

[garretwilson]

I've opened a new question on Stack Overflow to try to get to the bottom of this: Maven Artifact Resolver not seeing latest plugins on Maven Central on my machine.

[andrzejj0]

Garret, I didn't mean you had to delete the whole ~/.m2/repository, but just the subfolder containing the dependency that caused problems within it. This way maven will redownload the dependency with the correct version this time.

As to why this happens, it's best to ask on either https://issues.apache.org/jira or on Maven users' mailing lists -- users@maven.apache.org. That last one might feel like the old USENET times, but I think it should be the best resource.

[garretwilson]

Good morning, @ajarmoniuk .

Garret, I didn't mean you had to delete the whole ~/.m2/repository, but just the subfolder containing the dependency that caused problems within it.

Right, but how do I know at any time which subfolder contains a dependency that is "caus[ing] problems within it"? I only knew in this case because you were nice enough to respond to the ticket and post your test results for this project. But I have many other projects with many other dependencies. How am I to know that these few are the only ones with problems? If Maven is "stuck" at some point in the past on my machine, I likely have dozens of dependencies for which Versions Maven Plugin would should out-of-date information for, but I have no way of knowing which ones they are (because of the nature of this problem). You see what I mean?

As to why this happens, it's best to ask on either https://issues.apache.org/jira or on Maven users' mailing lists -- users@maven.apache.org.

I'll do that as well—thanks for the tip.

[andrzejj0]

Going back to that artifact: the request for available versions is done using this API call: https://maven.apache.org/resolver/maven-resolver-api/apidocs/org/eclipse/aether/RepositorySystem.html#resolveVersionRange(org.eclipse.aether.RepositorySystemSession,org.eclipse.aether.resolution.VersionRangeRequest).

And I'm attaching here some logs for mvn org.codehaus.mojo:versions-maven-plugin:2.15.0:display-plugin-updates "-Dmaven.version.ignore=.*-M.*" -X on a Mac (previous logs were from a Linux box):

[DEBUG] Could not find metadata com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml in local (/User
s/ajarmoniuk/.m2/repository)
[DEBUG] Skipped remote request for com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, locally cac
hed 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.4.1
[DEBUG] [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].effectiveVersion=2.1.3
[DEBUG] [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].specified=true
[DEBUG] Checking org.apache.maven.plugins:maven-antrun-plugin for updates newer than 3.1.0
[DEBUG] Found ignored versions: .*-M.* (regex)

As you can see, local repo is consulted for metadata.

By the way, we do test the plugin against Linux, MacOS and Windows, with nothing like you provided occurring. So this is quite strange. I wonder if there might be something to tweak regarding the backend call.

[garretwilson]

@ajarmoniuk I note that your machine is also skipping a remote request for com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:

[DEBUG] Skipped remote request for com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, locally cached metadata up-to-date

I would imagine that there is some timestamp or something that says "used the cached version and don't actually contact Maven Central until X time has passed since time the information was cached". Part of the problem here is that I don't actually know which timestamp this API is using, so I can't check it manually.

[andrzejj0]

Well, I don't like the fact that it's using the local repo in the first place. Perhaps I'll find a way of skipping that altogether.

[garretwilson]

… "-Dmaven.version.ignore=.*-M.*" -X …

You can take out the ignore altogether, if you want, to reduce the variables. Mine is skipping com.akathist.maven.plugins.launch4j:launch4j-maven-plugin whether or not I have ignores specified, so I am no longer testing with ignores enabled, just to prevent confusion. I'll go back to testing that once I get this cache mystery resolved.

[garretwilson]

@ajarmoniuk , how do I turn on debug logging for Versions Maven Plugin?

I'm looking at the DisplayPluginUpdatesMojo.java source code. (I've only looked for a few seconds, so I could be completely off here.) I'm seeing this:

        for (Plugin plugin : plugins) {
            String coords = ArtifactUtils.versionlessKey(plugin.getGroupId(), plugin.getArtifactId());
            String version = ofNullable(plugin.getVersion()).orElse(parentPlugins.get(coords));

            boolean versionSpecifiedInCurrentPom = pluginsWithVersionsSpecified.contains(coords);
            if (!versionSpecifiedInCurrentPom && !processUnboundPlugins && parentPlugins.containsKey(coords)) {
                getLog().debug("Skip " + coords + ", version " + version + " is defined in parent POM.");
                getLog().debug("Use the \"processUnboundPlugins\" parameter to see these updates.");
                continue;
            }

            getLog().debug("Checking " + coords + " for updates newer than " + version);

Without look at anything else, for every plugin I should see either a "Checking …" or "Skip …" message, right? How do I turn on debugging to see that?

[andrzejj0]

-X or --debug

[garretwilson]

Ah, right. I had done that earlier, but then ignored the rest of the output because I got sidetracked by the "Skipped remote request …" message. But I'm not even sure that's relevant—that may (or may not) be about metadata for already-downloaded artifacts.

In any case (focusing on com.akathist.maven.plugins.launch4j:launch4j-maven-plugin because that (correctly) shows up for you but doesn't even appear for me, and has nothing to do with versions ignore), here is the relevant output:

[DEBUG] Checking com.akathist.maven.plugins.launch4j:launch4j-maven-plugin for updates newer than 2.1.3
[DEBUG] Determining update check for artifact com.akathist.maven.plugins.launch4j:launch4j-maven-plugin (C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata-central.xml) from central (https://repo.maven.apache.org/maven2)
[DEBUG] Searching for central.maven-metadata-central.xml.lastUpdated in resolution tracking file.
[DEBUG] Reading resolution-state from: C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\resolver-status.properties
[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

[cstamas]

@garretwilson do you by any chance use some sort of caching proxy (artifactory, nexus, whatever)...

[garretwilson]

… do you by any chance use some sort of caching proxy (artifactory, nexus, whatever)...

None whatsoever. This is a pure, plain Maven installation.

[garretwilson]

The debug output says that is is "determining update check … from central …" and then "Reading resolution-state from … resolver-status.properties". It's not clear to me whether resolver-status.properties influences the "update check from central", but in any case, here is the contents of my resolver-status.properties:

#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

Nothing seems amiss here. Assuming 1662676475074 is a Unix epoch timestamp, it matches the human-readable date in the comments, and reflects a date in the past.

[garretwilson]

I cloned the Versions Maven Plugin source code, and the string "Determining update check for artifact" does not appear anywhere in it, so I presume that this debug line comes from some other plugin (perhaps Maven Artifact Resolver?).

[garretwilson]

Interesting that the string "Determining update check for artifact" does not appear in the source code for maven-resolver either …

[cstamas]

It comes from resolver, yes.

It is late night in Europe, and your first mail arrived at 6pm local time today. Please be patient :)

Will take a peek my morning.

Tamas

On Wed, May 24, 2023, 23:11 Garret Wilson @.***> wrote:

I cloned the Versions Maven Plugin source code, and the string "Determining update check for artifact" does not appear anywhere in it, so I presume that this debug line comes from some other plugin (perhaps Maven Artifact Resolver?).

— Reply to this email directly, view it on GitHub https://github.com/mojohaus/versions/issues/959#issuecomment-1561931477, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALA3PW6DTEHC4IJBIMNLTXHZ2PDANCNFSM6AAAAAAYI2SM4E . You are receiving this because you commented.Message ID: @.***>

[garretwilson]

Please be patient :)

Oh, no problem! I'm just happy to know someone is looking into this; thanks for letting me know. Have a restful night.

[cstamas]

Whoops, that reply above was meant for ML... Sorry. Is late night... 😄

[andrzejj0]

@ajarmoniuk I note that your machine is also skipping a remote request for com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:

[DEBUG] Skipped remote request for com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, locally cached metadata up-to-date

I would imagine that there is some timestamp or something that says "used the cached version and don't actually contact Maven Central until X time has passed since time the information was cached". Part of the problem here is that I don't actually know which timestamp this API is using, so I can't check it manually.

I was already off for that day. 6 am here now, back on.

It comes from Aather, used by Resolver, from org.eclipse.aether:aether-impl to be precise (Resolver uses Eclipse Aether).

[andrzejj0]

@cstamas I see you've cloned this repo. The lookup is done here: https://github.com/mojohaus/versions/blob/0fe821e400fe917b5fc342fe5712071dd0490473/versions-common/src/main/java/org/codehaus/mojo/versions/api/DefaultVersionsHelper.java#L278

[cstamas]

@ajarmoniuk I did check it and @slawekjaranowski also confirmed... so I am now more inclined that something else in that build triggered the legacy code, that left local repo in state that resolver assumed "no update needed".

Given we all tried to reproduce Garret's problem (and failed to do so), I'd really like to see a reproducer. At the same time I am almost certain, it is impossible to produce one. As this very much can be not only "one build" (like a simple reproducer), but the fact that his local repo is accessed by multiple tools,

[cstamas]

Interesting observation:

I have

[DEBUG] Checking com.akathist.maven.plugins.launch4j:launch4j-maven-plugin for updates newer than 2.1.3
[DEBUG] Found ignored versions: .*-SNAPSHOT (regex), .*-alpha(?:-?\d+)? (regex), .*-beta(?:-?\d+)? (regex), .*-M(?:-?\d+)? (regex), .*-RC(?:-?\d+)? (regex), .*-pfd(?:-?\d+)? (regex)
[DEBUG] Could not find metadata com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml in local (/home/cstamas/tmp/versions-959/local)
[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

@ajarmoniuk have

[DEBUG] Could not find metadata com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml in local (/Users/ajarmoniuk/.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

while @garretwilson have

[DEBUG] Checking com.akathist.maven.plugins.launch4j:launch4j-maven-plugin for updates newer than 2.1.3
[DEBUG] Determining update check for artifact com.akathist.maven.plugins.launch4j:launch4j-maven-plugin (C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata-central.xml) from central (https://repo.maven.apache.org/maven2)
[DEBUG] Searching for central.maven-metadata-central.xml.lastUpdated in resolution tracking file.
[DEBUG] Reading resolution-state from: C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\resolver-status.properties
[DEBUG] [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].version=2.1.3

Andrzej and mine are same. While Garret 2nd and 3rd line does NOT come from resolver (as for Andrzej and me), but from here: https://github.com/apache/maven/blob/maven-3.9.1/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L76 https://github.com/apache/maven/blob/maven-3.9.1/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L262

None of these strings appear in resolver. Like something "derailed" Maven from resolver to compat... Very strange,

[cstamas]

@garretwilson can you tell us something about:

• your environment
• exact java -version, maven version mvn -v (3.9.1 I guess, like it was mentioned somewhere)
• maven settings.xml
• possible maven extensions installed (maven and build, and all, in /lib or .mvn or whatever)
• whatever else that comes to your mind :smile: