Quarkus universe bom unaligned dependencies

[jtnord]

Describe the bug

the quarkus universe bom io.quarkus:quarkus-universe-bom:2.16.1.Final contains unaligned versions

that is there are dependencies that are managed at lower versions than a dependency also in the bom requires.

for example (there are many others):

org.reactivestreams:reactive-streams is managed to version 1.0.3
io.smallrye.reactive:mutiny is managed to version 1.9.0

1.9.0 of io.smallrye.reactive:mutiny depends on org.reactivestreams:reactive-streams:1.0.4

Expected behavior

the bom is importable and all dependencies and their transitive dependencies managed by the bom are satisfiable without a dependency version being downgraded.

Actual behavior

artifact dependencies are downgraded.

How to Reproduce?

create a maven project with the maven-enforcer and set the requireUpperBounds rule. import the universe bom in dependencymanagement and all dependencies that are in the bom as dependencies (without their version being defined)

run the build to trigger the enforcer.

expect no upper bounds issues (there are lots).

Output of uname -a or ver

Hal2001

Output of java -version

jdk-11.0.15+10

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.1.FINAL

Build tool (ie. output of mvnw --version or gradlew --version)

maven 3.8.6

Additional information

No response

[jtnord]

related to (but distinct from ) #26067

[geoand]

cc @cescoffier @aloubyansky

[aloubyansky]

That's how they are configured in https://github.com/quarkusio/quarkus/blob/main/bom/application/pom.xml
Whether that's on purpose, in this specific case, it's a question for @cescoffier and @jponge.

[cescoffier]

There are no code differences between Reactive Streams 1.0.3 and 1.0.4. So we can update.

Note that in Quarkus 3, I'm not sure we will continue to manage that dependency, as we are switching to Flow (part of the JDK).

[jponge]

We'll still have to ship it (e.g., RESTEasy / Reactive Messaging will support both APIs)

[jtnord]

just to be absolutely clear reactive-streams was just one example - there are many more.

[aloubyansky]

If it'a not about a specific misalignment of this kind then, generally, it's ok, unless it actually breaks something.
A dependency tree of pretty pretty much any non-trivial project will contain these kinds of misalignments. If we were seriously strict about it, we'd have to perform coordinated releases across a large part of the Java ecosystem.
Having said that, there could still be version updates that we simply overlooked and that would make sense to fix.

[famod]

I remember a discussion about requireUpperBounds a while ago.
I still think it's a tool that should be consulted when the BOM is changed so that no "misalignment" slips in unnoticed.

[gsmet]

I will close this one.
We can improve on specific projects that are in our reach but we can't guarantee everything is aligned in our dependency tree as we would have to release a significant part of the ecosystem to keep things aligned (including projects we don't maintain): that's also why we have our BOM.

[jtnord]

but we can't guarantee everything is aligned in our dependency tree as we would have to release a significant part of the ecosystem to keep things aligned (including projects we don't maintain): that's also why we have our BOM.

FTR yes you can and have complete control of this as you know what dependencies are pulled in by Quarkus universe- if you add the versions to the BOM then, it will be aligned (and the bom should push the upper version)

[gsmet]

Well, I think that's what we have been doing. Except we don't enforce the upper bound.