Dependabot Maven not finding latest version of a dependency #6637

updater | INFO <job_601547269> Checking if com.redhat.quarkus.platform:quarkus-bom 2.13.5.Final-redhat-00002 needs updating
  proxy | 2023/02/10 11:11:04 [180] GET https://maven.repository.redhat.com:443/ga/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml
  proxy | 2023/02/10 11:11:04 [180] 200 https://maven.repository.redhat.com:443/ga/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml
  proxy | 2023/02/10 11:11:04 [182] HEAD https://maven.repository.redhat.com:443/ga/com/redhat/quarkus/platform/quarkus-bom/2.13.5.Final-redhat-00002/quarkus-bom-2.13.5.Final-redhat-00002.pom
  proxy | 2023/02/10 11:11:04 [182] 200 https://maven.repository.redhat.com:443/ga/com/redhat/quarkus/platform/quarkus-bom/2.13.5.Final-redhat-00002/quarkus-bom-2.13.5.Final-redhat-00002.pom
updater | INFO <job_601547269> Latest version is 2.13.5.Final-redhat-00002
updater | INFO <job_601547269> No update needed for com.redhat.quarkus.platform:quarkus-bom 2.13.5.Final-redhat-00002

According to https://maven.repository.redhat.com/ga/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml there is a newer version available: 2.13.5.SP1-redhat-00002.

<metadata>
  <groupId>com.redhat.quarkus.platform</groupId>
  <artifactId>quarkus-bom</artifactId>
  <versioning>
    <latest>2.13.5.SP1-redhat-00002</latest>
    <release>2.13.5.SP1-redhat-00002</release>
    <versions>
      <version>2.2.3.Final-redhat-00013</version>
      <version>2.2.3.SP1-redhat-00002</version>
      <version>2.2.3.SP2-redhat-00001</version>
      <version>2.2.5.Final-redhat-00006</version>
      <version>2.2.5.Final-redhat-00007</version>
      <version>2.2.5.SP1-redhat-00001</version>
      <version>2.2.5.SP2-redhat-00003</version>
      <version>2.7.5.Final-redhat-00011</version>
      <version>2.7.6.Final-redhat-00006</version>
      <version>2.7.6.Final-redhat-00009</version>
      <version>2.7.6.Final-redhat-00011</version>
      <version>2.7.6.Final-redhat-00012</version>
      <version>2.13.5.Final-redhat-00002</version>
      <version>2.13.5.SP1-redhat-00002</version>
    </versions>
    <lastUpdated>20230126102524</lastUpdated>
  </versioning>
</metadata>

Dependabot doesn't seem to be picking up this version.

Native package manager behavior

No response

Images of the diff or a link to the PR, issue, or logs

Latest dependabot log (as of February 10, 2023): https://github.com/quarkusio/quarkus-super-heroes/network/updates/601547269

Smallest manifest that reproduces the issue

<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>io.quarkus.sample.super-heroes</groupId>
  <artifactId>rest-villains</artifactId>
  <version>1.0</version>
  <name>Quarkus Sample :: Super-Heroes :: Villains Microservice</name>
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
    <quarkus.platform.group-id>com.redhat.quarkus.platform</quarkus.platform.group-id>
    <quarkus.platform.version>2.13.5.Final-redhat-00002</quarkus.platform.version>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>${quarkus.platform.group-id}</groupId>
        <artifactId>${quarkus.platform.artifact-id}</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-resteasy-reactive-jackson</artifactId>
    </dependency>
  </dependencies>
  <repositories>
    <repository>
      <id>red-hat-enterprise-maven-repository</id>
      <url>https://maven.repository.redhat.com/ga/</url>
      <releases>
        <enabled>true</enabled>
      </releases>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>
  <pluginRepositories>
    <pluginRepository>
      <id>red-hat-enterprise-maven-repository</id>
      <url>https://maven.repository.redhat.com/ga/</url>
      <releases>
        <enabled>true</enabled>
      </releases>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </pluginRepository>
  </pluginRepositories>
</project>

The text was updated successfully, but these errors were encountered:

deivid-rodriguez · 2023-02-10T15:31:12Z

Hi!

I don't know much about Java versioning, but after looking a bit into it, it seems Maven agrees with Dependabot?

$ java -jar ~/.m2/repository/org/apache/maven/maven-artifact/3.9.0/maven-artifact-3.9.0.jar 2.13.5.SP1-redhat-00002 2.13.5-Final-redhat-00002 
Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 2.13.5.SP1-redhat-00002 -> 2.13.5-sp-1-redhat-2; tokens: [2, 13, 5, [sp, [1, [redhat, [2]]]]]
   2.13.5.SP1-redhat-00002 < 2.13.5-Final-redhat-00002
2. 2.13.5-Final-redhat-00002 -> 2.13.5-redhat-2; tokens: [2, 13, 5, [[redhat, [2]]]]

Could you open an issue with Maven to clarify if this is bug or expected behavior? I think https://issues.apache.org/jira/projects/MNG/issues/MNG-5987?filter=allopenissues may be the place?

Regardless of that, I guess we should add logic to Dependabot to consider the latestVersion metadata, and only if not present (I guess it's optional?) use manual ordering?

Summoning @soulus13 in case he can bring some light here 🙏 (if you find my random pings annoying please let me know, you've been just too helpful for us, so I think it's worth asking, but I don't want to bother you!)

edeandrea · 2023-02-10T15:34:58Z

@aloubyansky ^^^

edeandrea · 2023-02-10T15:36:07Z

Thank you @deivid-rodriguez for the info.

(if you find my random pings annoying please let me know, you've been just too helpful for us, so I think it's worth asking, but I don't want to bother you!)

I don't find it annoying at all. I'm going to do the same with some of our folks here!

edeandrea · 2023-02-10T15:46:26Z

Your example above is a little wrong though (you used 2.13.5.SP1-redhat-00002 and 2.13.5-Final-redhat-00002. It should be 2.13.5.SP1-redhat-00002 and 2.13.5.Final-redhat-00002.

Nonetheless the results are the same:

$ java -jar ~/.m2/repository/org/apache/maven/maven-artifact/3.8.4/maven-artifact-3.8.4.jar 2.13.5.SP1-redhat-00002 2.13.5.Final-redhat-00002

Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 2.13.5.SP1-redhat-00002 -> 2.13.5.sp-1-redhat-2; tokens: [2, 13, 5, sp, [1, [redhat, [2]]]]
   2.13.5.SP1-redhat-00002 < 2.13.5.Final-redhat-00002
2. 2.13.5.Final-redhat-00002 -> 2.13.5-redhat-2; tokens: [2, 13, 5, [redhat, [2]]]

deivid-rodriguez · 2023-02-10T15:51:48Z

Oh, thanks for correcting it. I tried a bunch of combinations and copied a wrong test case. Anyways, I could not make logic from the results. I did read the docs at https://maven.apache.org/ref/4.0.0-alpha-4/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html, and found that we do implement the same qualifier priority in Dependabot.

aloubyansky · 2023-02-10T17:31:32Z

@deivid-rodriguez thanks for the analysis, we should have verified it before making noise about it. The confusing part is that an SP generally appears later than a Final:

java -jar ~/.m2/repository/org/apache/maven/maven-artifact/3.8.4/maven-artifact-3.8.4.jar 2.13.5.SP1 2.13.5.Final
Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 2.13.5.SP1 -> 2.13.5.sp-1; tokens: [2, 13, 5, sp, [1]]
   2.13.5.SP1 > 2.13.5.Final
2. 2.13.5.Final -> 2.13.5; tokens: [2, 13, 5]

However, the presence of the redhat qualifier apparently reverses it.

About taking into account

<metadata>
  <groupId>com.redhat.quarkus.platform</groupId>
  <artifactId>quarkus-bom</artifactId>
  <versioning>
    <latest>2.13.5.SP1-redhat-00002</latest>
    <release>2.13.5.SP1-redhat-00002</release>

we need to make sure that if suddenly we release 2.7.7, it doesn't appear as the latest recommended release overall.

edeandrea · 2023-02-10T17:44:40Z

However, the presence of the redhat qualifier apparently reverses it.

Its really just adding a - followed by anything that introduces it

$ java -jar ~/.m2/repository/org/apache/maven/maven-artifact/3.8.4/maven-artifact-3.8.4.jar 2.13.5.SP1-x 2.13.5.Final-x    
Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 2.13.5.SP1-x -> 2.13.5.sp-1-x; tokens: [2, 13, 5, sp, [1, [x]]]
   2.13.5.SP1-x < 2.13.5.Final-x
2. 2.13.5.Final-x -> 2.13.5-x; tokens: [2, 13, 5, [x]]

Maven doesn't actually create a token for Final, as you saw in your example @aloubyansky

java -jar ~/.m2/repository/org/apache/maven/maven-artifact/3.8.4/maven-artifact-3.8.4.jar 2.13.5.SP 2.13.5.Final    
Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 2.13.5.SP -> 2.13.5.sp; tokens: [2, 13, 5, sp]
   2.13.5.SP > 2.13.5.Final
2. 2.13.5.Final -> 2.13.5; tokens: [2, 13, 5]

deivid-rodriguez · 2023-02-10T17:49:43Z

No worries about noise, it's a good learning exercise for us and maybe a way to get in touch with the upstream maven project!

Regarding the priority here, I observed the same thing. SP is documented as higher than final, but I guess that's only when it's the only qualifier? I guessp1-redhat is considered a custom qualifier, and custom qualifier always have prerelease status and always sort before "final"?

And regarding considering latest, good point! I assumed it was what the author considered the "highest" release, but it could also be "latest", in the chronological sense!

soulus13 · 2023-02-10T18:02:05Z

@deivid-rodriguez, surely not bothering me 😃 And version parsing logic in maven when not staying withing the accepted versioning x.y[.z][-A] really changes.

For this case a similar example is even listed in the maven wiki https://maven.apache.org/pom.html#Version_Order_Specification:
"1-sp-1" < "1-ga-1" = "1-1" (trailing "null" values at each hyphen)
so indeed, looks like "it is a feature, not a bug" 😃

aloubyansky · 2023-02-10T18:04:36Z

Speaking of the author preferences when it comes to the latest recommendations, in Quarkus we have a service that provides this information per "stream", which is typically tied to major.minor in the version. Could we think of ways to integrate that in some form (e.g. a REST call) to fetch the latest recommended versions for specific projects?

For Quarkus we'd cover BOM versions and Maven plugins primarily. However, we have more sophisticated version update support than that. We can analyze which Quarkus extensions are found in the project and suggest the latest recommended combination of those for a given project. Could that be something dependabot would provide some kind of plugin for?

edeandrea · 2023-02-10T18:06:25Z

Just my opinion here @aloubyansky, but I would think that dependabot would want to remain neutral to any potential Java-based frameworks and leave it to the package managers to do their work (i.e. Maven & Gradle)?

aloubyansky · 2023-02-10T18:06:52Z

Basically, it'd not just about latest version updates but taking into account compatibility between the upgraded components.

aloubyansky · 2023-02-10T18:08:17Z

Sure, just in case it could be interesting to provide version update suggestions based on compatibility info.

edeandrea · 2023-02-10T18:18:09Z

I wonder if the same problem exists if using Gradle. I could probably do a little POC and see.

jeffwidman · 2023-02-10T18:49:11Z

I would think that dependabot would want to remain neutral to any potential Java-based frameworks and leave it to the package managers to do their work (i.e. Maven & Gradle)?

Correct, despite the fact that today we re-implement Maven / Gradle parsing via Ruby/Regex (but poorly). We very much want to move away from that model toward Dependabot being the glue code and leave version resolving to the native package manager tools. Ideally Dependabot finds the manifests, passes them to the native package manager, then takes the output and turns it into a useful PR. However, that will take a bit of time, which is why issues like #1164 are still open.

Practically speaking, that means that if today Dependabot's brittle Ruby/regexes are buggy compared to Maven/Gradle behavior, then we will fix those bugs. But if you're looking for us to extend those to support parsing additional fields, then we're unlikely to do that as we'd rather put the effort into shifting over to the native tooling. Similarly, if you want non-standard behavior or extensions to the native package manager behavior, then I suggest working with the upstream package manager as it'd be pointless to do that here if we plan to rip that all out eventually when we switch to the native tooling.

aloubyansky · 2023-02-10T19:10:41Z

It's exactly about delegating version updates to tools that can suggest not individual artifact updates but a set that is known to be related but only to those specialized tools.

For example today I have a PoC that reads a multi module project, identifies Quarkus bits in it and suggests which properties, dependencies, BOM imports and plugins should be updated, removed or added pointing to pom.xml files where those changes should be applied.

This could be integrated into a maven plugin or, i guess, a GitHub bot, which is why I wanted to share the idea.

jeffwidman · 2023-02-10T19:39:02Z

The discussion has wandered a little from the original bug report, so I'm unclear:
Is there still an open bug report here or did we confirm that matches Maven upstream behavior so this can be closed?

I realize there's an implicit feature request for making some bits of this pluggable, but as I mentioned above, the best place is the native package manager for this, and then when we shift over to that we can discuss ways to make it possible to also pull in plugins for native tooling. Although TBH even once it's pluggable it'd probably still require running Dependabot standalone yourself, as we're unlikely to pull in custom plugins in the standard install we would run within the Dependabot service on GitHub.

edeandrea · 2023-02-10T19:42:38Z

I think the original issue, although unresolved, is not dependabot's to resolve, based on how maven sees things. You can go ahead @jeffwidman and close it out. If something comes to light later on I can always re-open it.

I really appreciate the promptness of everyone's responses!

aloubyansky · 2023-02-10T19:43:40Z

I agree. Thanks!

deivid-rodriguez · 2023-02-10T19:54:39Z

I think, based on a bit more testing with Maven, we should probably look it versioning > latest field and trust what's in there.

This is what I tried (probably there's an easier way to check this but I wasn't sure how to ask mvn: "tell me what you think it's the latest version"):

Set <version>[2.13.5.Final-redhat-00002,)</version> in the pom.xml file.
Run mvn install.
Observe both 2.13.5.Final-redhat-00002 and 2.13.5.SP1-redhat-00002 installed at ~/.m2/repository/...
Change pom.xml to <version>[2.13.5.SP1-redhat-00002,)</version>.
Clear ~/.m2.
Run mvn install again.
Observe only 2.13.5.SP1-redhat-00002 installed.

So it seems authors can override order if they want to and mvn will respect that?

Doing this ourselves too has the added benefit that we don't need to do any sorting at all.

edeandrea · 2023-02-10T20:18:28Z

I was curious about how Gradle works, so I created https://github.com/edeandrea/quarkus-gradle-dependabot-test and enabled dependabot. I use the same version (2.13.5.Final-redhat-00002).

First thing I noticed @aloubyansky is that it does not work based on the way we structure our projects. It does not look in gradle.properties for things. On https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file I see this:

[3] Dependabot doesn't run Gradle but supports updates to the following files: build.gradle, build.gradle.kts (for Kotlin projects), and files included via the apply declaration that have dependencies in the filename. Note that apply does not support apply to, recursion, or advanced syntaxes (for example, Kotlin's apply with mapOf, filenames defined by property).

It seems that once I move things directly into settings.gradle and build.gradle, dependabot sees updates to settings.gradle (it opened https://github.com/edeandrea/quarkus-gradle-dependabot-test/pull/1)

So the documentation there should also include settings.gradle. Should it also examine gradle.properties?

This original problem does seem to exist with Gradle as well. See https://github.com/edeandrea/quarkus-gradle-dependabot-test/network/updates/601855201

updater | INFO <job_601855201> Checking if com.redhat.quarkus.platform:quarkus-bom 2.13.5.Final-redhat-00002 needs updating
  proxy | 2023/02/10 20:15:11 [024] GET https://repo.maven.apache.org:443/maven2/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml
  proxy | 2023/02/10 20:15:11 [024] 404 https://repo.maven.apache.org:443/maven2/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml
  proxy | 2023/02/10 20:15:11 [026] GET https://maven.repository.redhat.com:443/ga/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml
  proxy | 2023/02/10 20:15:11 [026] 200 https://maven.repository.redhat.com:443/ga/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml
updater | INFO <job_601855201> Latest version is 2.13.5.Final-redhat-00002
updater | INFO <job_601855201> No update needed for com.redhat.quarkus.platform:quarkus-bom 2.13.5.Final-redhat-00002

My guess is its for the same reason?

aloubyansky · 2023-02-10T20:24:16Z

@deivid-rodriguez We as authors don't really control this metadata apart from release scheduling.
I just tried a simple install into my local Maven repo and here is what I got releasing 1.0.0 then 2.0.0 then 1.0.1:

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>org.acme</groupId>
  <artifactId>acme-app</artifactId>
  <versioning>
    <release>1.0.1</release>
    <versions>
      <version>1.0.0</version>
      <version>2.0.0</version>
      <version>1.0.1</version>
    </versions>
    <lastUpdated>20230210201325</lastUpdated>
  </versioning>
</metadata>

Notice, there is no latest. It might depend on a specific Maven repo manager what it will be.

@edeandrea yes, i'm pretty sure the reason is the same.

edeandrea · 2023-02-10T20:26:16Z

So that means we can't rely on maven-metadata.xml to tell anyone what the latest release of a particular major.minor version is. It's only tracking the latest release based on chronological order.

aloubyansky · 2023-02-10T20:30:45Z

Right. Dependabot shouldn't change anything in that regard though.

deivid-rodriguez · 2023-02-10T20:35:10Z

@deivid-rodriguez We as authors don't really control this metadata apart from release scheduling.

I see, thanks for clarifying that. I found the docs here:

https://maven.apache.org/ref/3.9.0/maven-repository-metadata/repository-metadata.html#versioning

Indeed, it seems just chronological order.

So, my conclusions so far, Dependabot is getting this right and maven is getting this wrong??

edeandrea · 2023-02-10T20:36:29Z

So, my conclusions so far, Dependabot is getting this right and maven is getting this wrong??

I wouldn't say that, otherwise shouldn't I see a PR in my repo updating from 2.13.5.Final-redhat-00002 to 2.13.5.SP1-redhat-00002?

See dependabot/dependabot-core#6637 as to why dependabot didn't do this on its own.

deivid-rodriguez · 2023-02-10T20:42:02Z

I wouldn't say that, otherwise shouldn't I see a PR in my repo updating from 2.13.5.Final-redhat-00002 to 2.13.5.SP1-redhat-00002?

Mmmm our conclusion was that in this case 2.13.5.Final-redhat-00002 is higher than 2.13.5.SP1-redhat-00002 so that would be a downgrade, no?

edeandrea · 2023-02-10T20:47:28Z

That's what maven thinks, but in reality SP1 is an uogrqde

deivid-rodriguez · 2023-02-10T20:54:15Z

Oh, sure, but Dependabot needs rules, it can't read library author's minds. If library foo latest version is 4.0.0, and foo's author releases 3.99.99 including new code with juicy features and fixes, Dependabot should not really propose an upgrade there. Instead library foo users should go bug library author and ask her to release the new code as 4.0.1.

edeandrea · 2023-02-10T20:58:12Z

Right. I think what we deduced was that dependabot's rules are consistent with maven's.

deivid-rodriguez · 2023-02-10T20:59:48Z

If we really think 2.13.5.SP1-redhat-00002 is an upgrade over 2.13.5.Final-redhat-00002, and this is a bug in Maven, then we should go ask Maven about this. But according to the docs mentioned by @soulus13 before, this looks like a feature.

However, I still think there's a bug in Maven anyways because it's actually choosing 2.13.5.SP1-redhat-00002 as the latest version.

So, there's two options:

This is a bug in maven version sorting (the result of Dependabot Maven not finding latest version of a dependency #6637 (comment) is buggy). Then maven needs to fix the bug, the documentation, and after that we should also fix it in Dependabot's side.
There's a bug in maven version selection (the result of Dependabot Maven not finding latest version of a dependency #6637 (comment) is buggy). Then maven needs to fix this and Dependabot does not need to change anything because it's getting this right.

edeandrea · 2023-02-10T21:17:34Z

However, I still think there's a bug in Maven anyways because it's actually choosing 2.13.5.SP1-redhat-00002 as the latest version.

Where are you getting that? Maven is choosing 2.13.5.Final-redhat-00002 as the latest version, which is consistent with dependabot.

$ java -jar ~/.m2/repository/org/apache/maven/maven-artifact/3.8.4/maven-artifact-3.8.4.jar 2.13.5.SP1-redhat-00002 2.13.5.Final-redhat-00002 

Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 2.13.5.SP1-redhat-00002 -> 2.13.5.sp-1-redhat-2; tokens: [2, 13, 5, sp, [1, [redhat, [2]]]]
   2.13.5.SP1-redhat-00002 < 2.13.5.Final-redhat-00002
2. 2.13.5.Final-redhat-00002 -> 2.13.5-redhat-2; tokens: [2, 13, 5, [redhat, [2]]]

deivid-rodriguez · 2023-02-10T21:18:36Z

I tried to contact the Maven project about this and will post any updates I get, and link to a public discussion upstream about this if/when it's created.

I'll close this ticket for now, since this does not seem a Dependabot issue (at the moment). We can reopen if it turns out we need to fix anything on our side.

deivid-rodriguez · 2023-02-10T21:25:40Z

Where are you getting that? Maven is choosing 2.13.5.Final-redhat-00002 as the latest version, which is consistent with dependabot.

Maybe I did it wrong, but in #6637 (comment) I tried an idea to figure out what mvn install considers the latest version. I first set <version>[2.13.5.Final-redhat-00002,)</version> as a requirement, which in my understanding means >= 2.13.5.Final-redhat-00002, and both versions were downloaded. Then I set <version>[2.13.5.SP1-redhat-00002,)</version> and only 2.13.5.SP1-redhat-00002 was downloaded. So I took that as some logic in mvn install is considering 2.13.5.SP1-redhat-00002 as higher.

cstamas · 2023-02-13T15:31:00Z

Few responses to this thread:

correct: metadata/versioning/versions is chronological order of deployed version.
metadata/versioning/latest is considered in SNAPSHOT repositories only

cstamas · 2023-02-13T15:47:47Z

Also, it seems it is (old) code that is confused, maven-resolver (former aether) does it right:

take this example https://github.com/apache/maven-resolver/blob/master/maven-resolver-demos/maven-resolver-demo-snippets/src/main/java/org/apache/maven/resolver/examples/FindNewestVersion.java
apply this patch https://gist.github.com/cstamas/523e618558146550a1cc48b792285492
and run it's main method (even within IDE)
produced output

------------------------------------------------------------
FindNewestVersion
Resolving metadata com.redhat.quarkus.platform:quarkus-bom/maven-metadata.xml from /home/cstamas/Worx/apache-maven/maven-resolver/target/local-repo (enhanced)
Resolved metadata com.redhat.quarkus.platform:quarkus-bom/maven-metadata.xml from /home/cstamas/Worx/apache-maven/maven-resolver/target/local-repo (enhanced)
Resolving metadata com.redhat.quarkus.platform:quarkus-bom/maven-metadata.xml from red-hat-enterprise-maven-repository (https://maven.repository.redhat.com/ga/, default, releases+snapshots)
Downloading: https://maven.repository.redhat.com/ga/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml
Downloaded: https://maven.repository.redhat.com/ga/com/redhat/quarkus/platform/quarkus-bom/maven-metadata.xml (1010 B at 0.8 KB/sec)
Resolved metadata com.redhat.quarkus.platform:quarkus-bom/maven-metadata.xml from red-hat-enterprise-maven-repository (https://maven.repository.redhat.com/ga/, default, releases+snapshots)
Newest version 2.13.5.SP1-redhat-00002 from repository red-hat-enterprise-maven-repository (https://maven.repository.redhat.com/ga/, default, releases+snapshots)

Process finished with exit code 0

This means that version sorting (old) code in maven (as tested in comment #6637 (comment)) and maven-resolver disagree as well, and this may explain some subtle differences.

Created issue https://issues.apache.org/jira/browse/MNG-7690

aloubyansky · 2023-02-13T15:56:47Z

Thanks a lot @cstamas!

deivid-rodriguez · 2023-02-13T18:24:43Z

Thanks @cstamas, I subscribed to that ticket :)

edeandrea · 2023-11-21T15:25:12Z

Hello @deivid-rodriguez did any progress get made with the Maven team on this? Seems to still be an issue with dependabot unfortunately (even though its not dependabot's actual problem).

deivid-rodriguez · 2024-09-13T11:02:10Z

Sorry I never got back to you, I no longer maintain dependabot. Looking at https://issues.apache.org/jira/browse/MNG-7690, I see no further activity, so I guess the answer is no...

edeandrea added the T: bug 🐞 Something isn't working label Feb 10, 2023

deivid-rodriguez added the L: java:maven Maven packages via Maven label Feb 10, 2023

edeandrea added a commit to quarkusio/quarkus-super-heroes that referenced this issue Feb 10, 2023

Update Quarkus to 2.13.5.SP1-redhat-00002

4b89601

See dependabot/dependabot-core#6637 as to why dependabot didn't do this on its own.

deivid-rodriguez closed this as completed Feb 10, 2023

deivid-rodriguez mentioned this issue Feb 14, 2023

Version parsing for Maven PRD tag to treat as a pre-release tag may be incorrect #2044

Closed

deivid-rodriguez mentioned this issue Feb 28, 2023

fix: mark version with "preview" extension as pre-release (#6151) #6747

Closed

deivid-rodriguez mentioned this issue Mar 21, 2023

Not skipping unstable versions #6874

Closed

1 task

Dependabot Maven not finding latest version of a dependency #6637

Dependabot Maven not finding latest version of a dependency #6637

Comments

edeandrea commented Feb 10, 2023 • edited Loading

Is there an existing issue for this?

Package ecosystem

Package manager version

Language version

Manifest location and content before the Dependabot update

dependabot.yml content

Updated dependency

What you expected to see, versus what you actually saw

Native package manager behavior

Images of the diff or a link to the PR, issue, or logs

Smallest manifest that reproduces the issue

deivid-rodriguez commented Feb 10, 2023

edeandrea commented Feb 10, 2023

edeandrea commented Feb 10, 2023

edeandrea commented Feb 10, 2023

deivid-rodriguez commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

edeandrea commented Feb 10, 2023 • edited Loading

deivid-rodriguez commented Feb 10, 2023

soulus13 commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

edeandrea commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

edeandrea commented Feb 10, 2023

jeffwidman commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

jeffwidman commented Feb 10, 2023

edeandrea commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

deivid-rodriguez commented Feb 10, 2023 • edited Loading

edeandrea commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

edeandrea commented Feb 10, 2023

aloubyansky commented Feb 10, 2023

deivid-rodriguez commented Feb 10, 2023

edeandrea commented Feb 10, 2023 • edited Loading

deivid-rodriguez commented Feb 10, 2023

edeandrea commented Feb 10, 2023

deivid-rodriguez commented Feb 10, 2023 • edited Loading

edeandrea commented Feb 10, 2023

deivid-rodriguez commented Feb 10, 2023

edeandrea commented Feb 10, 2023 • edited Loading

deivid-rodriguez commented Feb 10, 2023

deivid-rodriguez commented Feb 10, 2023

cstamas commented Feb 13, 2023

cstamas commented Feb 13, 2023

aloubyansky commented Feb 13, 2023

deivid-rodriguez commented Feb 13, 2023

edeandrea commented Nov 21, 2023

deivid-rodriguez commented Sep 13, 2024

edeandrea commented Feb 10, 2023 •

edited

Loading

edeandrea commented Feb 10, 2023 •

edited

Loading

deivid-rodriguez commented Feb 10, 2023 •

edited

Loading

edeandrea commented Feb 10, 2023 •

edited

Loading

deivid-rodriguez commented Feb 10, 2023 •

edited

Loading

edeandrea commented Feb 10, 2023 •

edited

Loading