3.7.1 regression: No versions available for org.mvnpm.at.lit-labs:ssr-dom-shim:jar:[1.2.0,2) within specified range

[ppalaga]

Describe the bug

After upgrading to Quarkus 3.7.1, we get the following error from quarkus-maven-plugin:generate-code-tests mojo:

Failed to execute goal io.quarkus:quarkus-maven-plugin:3.7.1:generate-code-tests (default) on project quarkus-cxf-integration-test-wsdl2java: Quarkus code generation phase has failed: Failed to collect dependencies for io.quarkiverse.cxf:quarkus-cxf-deployment:jar:2.7.2-SNAPSHOT: Failed to collect dependencies at io.quarkus:quarkus-vertx-http-deployment:jar:3.7.1 -> io.quarkus:quarkus-vertx-http-dev-ui-resources:jar:3.7.1 -> org.mvnpm.at.mvnpm:vaadin-webcomponents:jar:24.3.0 -> org.mvnpm:lit:jar:3.0.0 -> org.mvnpm:lit-element:jar:4.0.4 -> org.mvnpm.at.lit-labs:ssr-dom-shim:jar:[1.2.0,2): No versions available for org.mvnpm.at.lit-labs:ssr-dom-shim:jar:[1.2.0,2) within specified range

Not sure what changed in the way how the codegen mojo resolves the dependencies, or in the dependencies themselves since 3.7.0.

Anyway, I wonder, why you @phillip-kruger moved the Vaadin stuff from the BOM? It all works good like that within Quarkus build tree because all is managed via build parent, but for end user apps and Quarkiverse testing the dependencies are much less deterministic and all the worms related to Vaadin using version ranges are coming out.

Expected behavior

The code generation should work

Actual behavior

The code generation fails

How to Reproduce?

Checkout quarkiverse/quarkus-cxf#1218 and build the integration-tests/wsdl2java

[quarkus-bot]

/cc @phillip-kruger (mvnpm)

[jamesnetherton]

Same issue observed in Camel Quarkus.

[geoand]

I saw this in Quarkus LangChain4j CI as well which is on Quarkus 3.7.0

[vmuzikar]

Keycloak is affected as well with Quarkus 3.7.0.CR1

[metacosm]

I see this with Quarkus Operator SDK as well with 3.7.1, I didn't have any problems with 3.7.0, though.

[vmuzikar]

Weird thing is 3.7.0.CR1 worked for us yesterday. Something must've changed retrospectively in mvn repo?

[gsmet]

That's the problem with using Maven ranges... Mvnpm might have pushed a component that requires a new version of something that is not pushed...

[gsmet]

I will reintroduce the versions in the BOM for now and try to make sure versions are OK and Dev UI works, we can discuss this when Phillip is back from PTO.

Not exactly how my day was planned :)

Thanks for the report, all!

[vmuzikar]

@gsmet Thanks! The fix will require a new release, I assume. So it'll be part of 3.7.2?

[gsmet]

So:

• the problem is due to lit-element 4.0.4 being published 12 hours ago and requiring ssr-dom-shim 1.2.0, which has not been published to Central
• lit-element 4.0.3 was requiring 1.1.2
• we are lucky, apparently, it didn't break applications as they still resolve to an old version of lit-element, it only affects building extensions (not sure why yet), which is annoying enough, I agree...

Yes, we will have to publish a new version.

[gsmet]

Update: Clément was able to trigger the build of the missing pieces and it's now possible to build things. You don't need any workaround anymore and we won't publish a new version (for now).

That doesn't fix the problem in the long run though so let's keep this issue open as we need to fix this one once and for all so that it never happens again.

[rsvoboda]

Quickstarts job also failed because of this issue - https://github.com/quarkusio/quarkus-quickstarts/actions/runs/7735235938/job/21090556678

[geoand]

Lots of Quarkus related things that run in CI overnight failed.

[ppalaga]

Thanks for taking care @gsmet!

Does anybody know whether we or somebody else discussed this with Vaadin? Maybe they just do not know how painful the version ranges are for their end users?

[maxandersen]

@ppalaga version ranges is commonly used in npm.js land because there they have default tooling that locks versions - so things don't get automatically picked up. So I don't think there is any point going to vaadin to plead when its because we missed to actually lock the versions in our builds.

That said - we were supposed to have our versions locked and its bit of a mystery what happened - we'll see what phiillips recalls when he is back on Monday.

[ppalaga]

version ranges is commonly used in npm.js land because there they have default tooling that locks versions - so things don't get automatically picked up. So I don't think there is any point going to vaadin to plead when its because we missed to actually lock the versions in our builds.

Interesting standpoint. I am not quite sure the conventions and tooling working in a certain way in nmp should imply that it is a good idea to use ranges with Maven. For me Maven always was like "Transitives chosen by a project should work OOTB and I can optionally choose to manage them at different versions if I care for some reason". Here, apparently, the transitives do not work OOTB and we must manage. That does not sound right for Maven.

[maxandersen]

Trust me - We have solutions for it. It's just we did not apply
It here. That's the issue.

If we applied it at mvnpm level we would not be able to have working js stack without making up intermediary imaginary releases whenever a dependency is released in npmjs land.

Version ranges are not bad on their own.

[ppalaga]

Oh, now I see what mvnpm actually is. So to avoid missing the packages in Maven Central, projects may choose to add https://repo.mvnpm.org/maven2 repository where the packages can be pulled/transformed from npm on the fly. Sorry for my ignorance.

[maxandersen]

Yeah. But that's just for dev/updating. Not something to add permanently.

[ppalaga]

Not something to add permanently.

OK, then at least up to the point when Quarkus fixes the dependecy management ;)

[phillip-kruger]

Hi all. First of all, apologies that this happened. I had a look at what caused it, and it was really "A Series of Unfortunate Events" :

1. Our locking is still working. It moved from the Quarkus BOM to the Build parent, but as far as I can tell, it's still locking the files.

2. a dependabot PR to upgrade lit-element was merged (Bump org.mvnpm:lit-element from 4.0.2 to 4.0.4 #38544). Because we lock version of the dependencies that is ranges in these libs, typically when merging these PRs, you also need to check if you also need to update other files that is locked. Unfortunately I did not communicate that well ( I assumed it's only me looking at mvnpm PRs).

3. the lit-element update, even without also looking at the locked dependencies, would have worked fine, even if the locked dependency is now out of range like what happened here. The only downside is that the range kick in again and maven download the metadata again everytime to check for newer versions. (This is why we lock). Unfortunately there was also big issues with oss.sonatype.org, and some files synced to central, but most failed. In this case lit-element synced, but not the dependency. During my PTO Andy did ping me about the oss sync issues and I logged an issue with sonatype, and the issue was resolved. But it did mean that the range could not be resolved.

4. When the dependency in the range was synced to central, the build could continue, and the dependency is still locking to the one in the lock file.

In general, I let vaadin "drive" the version of lit we use (as vaadin also use lit) so once I get a dependabot for a lit upgrade, I wait for a new vaadin version that also use the new lit before I update our version. I also then check all locks.

I hope this makes sense ? I'll do a update on the mvnpm libs to get everything up to date.

[phillip-kruger]

( I think we can close this now ?)

[geoand]

Thanks for the analysis @phillip-kruger !