Quarks 3.3.1 & Gradle app stopped building due to missing mvnpm

[kdubb]

Describe the bug

Our previously building and running Quarkus application using 3.3.1 has suddenly started failing to build (in the last week or so) due to a missing mvnpm listed in the BOM. The application is not using this and it is not using any extension (that I know of) that would use this.

Here's the Gradle failure:

> Could not resolve all files for configuration ':cloud-common:quarkusProdRuntimeClasspathConfigurationDeployment'.
   > Could not find any version that matches org.mvnpm.at.vaadin:component-base:[24.1.12,24.2).
     Versions that do not match:
       - 24.2.2
       - 24.2.1
       - 24.2.0
       - 24.1.11
       - 24.1.10
       - + 15 more
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/org/mvnpm/at/vaadin/component-base/maven-metadata.xml
     Required by:
         project :cloud-common > io.quarkus.platform:quarkus-bom:3.3.1 > org.mvnpm.at.vaadin:app-layout:24.1.4 > org.mvnpm.at.vaadin:a11y-base:24.1.12

Just to be clear we have made no changes to the application or build files. It just doesn't build any longer.

Expected behavior

That our application builds correctly, as it did before.

Actual behavior

Application fails to build.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

openjdk version "17.0.6" 2023-01-17

Quarkus version or git rev

3.3.1

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

8.3

Additional information

No response

[quarkus-bot[bot]]

/cc @glefloch, @quarkusio/devtools

[phillip-kruger]

Do you get this error when using the latest Quarkus version ?

[kdubb]

I have no idea. We were waiting for some fixes that are supposed to be in 3.5.1 but I'm not sure what the status of those items is yet; so we cannot upgrade just yet.

[kdubb]

It's a bit frightening to have an untouched build not be reproducible due to this.

[phillip-kruger]

Yes it is, this is fixed in the latest Quarkus (or even earlier). It has to do with version ranges. We lock these ranges in Quarkus, but missed this one :

<dependency>
                <groupId>org.mvnpm.at.vaadin</groupId>
                <artifactId>a11y-base</artifactId>
                <version>${vaadin.version}</version>
                <scope>runtime</scope>
            </dependency>

You can add this to your pom dependency management and see if that solves your issue. This should only be needed until you upgrade.

Let me know

[kdubb]

Any idea how to do this in Gradle?

[kdubb]

And what would I be using for ${vaadin.version}?

[phillip-kruger]

I am not sure how to do dependencyManagement in gradle, the version for vaadin in 3.3.1 is 24.1.4

[kdubb]

Adding the following snippet to the build.gradle.kts seems to get things working again...

configurations.all {
  resolutionStrategy.force("org.mvnpm.at.vaadin:component-base:24.1.11")
}

[phillip-kruger]

Great ! F.y.i 3.5.1 has been release in case you are waiting for that.

[kdubb]

Our application does not use this dependency so I could really care less what version it's locked to. This led me to just choose one Gradle listed as available; others might need to figure out what actual version they need.

[phillip-kruger]

Dev UI use that, so your application use it (when running in dev mode). Are you ok to close this issue ?

[kdubb]

F.y.i 3.5.1 has been release

Yes, I need to verify the fixes we were waiting for are in there and working.

Dev UI use that

In that case... is the version I've selected the right one? What version was my building using previously?

[phillip-kruger]

I think setting this should also solve your issue:

configurations.all {
  resolutionStrategy.force("org.mvnpm.at.vaadin:a11y-base:24.1.4")
}

(removing the component-base one you added. This should lock a11y-base to the same version as the rest of vaadin. Just remember to remove this when upgrading to 3.5.1

[phillip-kruger]

Let me know

[kdubb]

Your suggestion works as well. Thanks!

[phillip-kruger]

Closing here. Please reopen if needed.

[maxandersen]

@phillip-kruger are you expecting every user to fix this manually?

Does it affect 3.2 ? Or is it "just" in 3.3+ ?

[phillip-kruger]

It's fixed in this PR: https://github.com/quarkusio/quarkus/pull/35427 targeting 3.4.0. I now added a backport label to 3.2 (there is no backport for 3.3). This can be backported to both if there are going to be any more releases.

[maxandersen]

@phillip-kruger and I went and checked and the issue here with a11y-base being non-locked is present in: 3.3.0,3.3.1 and 3.3.2.

It is NOT in 3.2.x nor in 3.3+.

It was fixed in https://github.com/quarkusio/quarkus/pull/35723/commits/59c4f1d218243351701056e5916624c1a3767871 as part of #35723 3.3.2 backports 1

Thus for @kdubb - sorry for the inconvenience. Definitely a bug and should not have happened. The fix on locking in manually works but recommendation is you update to latest 3.3.x.

For going forward we do now bundle the devui js dependencies so we should not end up with this but we do still need to be aware of this possibly happening in 3.2.x updates and could in theory also happen for 3.x if a non-bundled js dependency creeps in.

@gsmet @aloubyansky @ia3andy fyi^

[kdubb]

Wondering if there's tooling to ensure this doesn't happen with any dependencies. For us we tend to stay fairly up to date and this wasn't a huge deal this time. In the future we will be switching to LTS releases as our code has stabilized and our verification processes are lengthening. At that point a non-reproducible build becomes more problematic.