Deployment BOM is not enforced on the build classpath

[aloubyansky]

Deployment (generally speaking the complete build) classpath is resolved by collecting Quarkus extensions (runtime artifacts) used in the applications and resolving their corresponding deployment artifacts with all their transitive dependencies. All the resolved deployment dependencies are then added "on top" of the application's runtime classpath and that is pretty much the build classpath of the application.
The runtime part of the classpath is managed by the platform's runtime BOM (imported in the application's pom or build.gradle).
The deployment part of the classpath today is also managed by the platform's runtime BOM. Which is insufficient, of course, because the runtime BOM includes none of the deployment dependencies.

In case of a Maven project, we do a kind of compensation by injecting collected extension versions into a set of managed dependencies obtained from the runtime BOM. That is still insufficient, although it appears to have worked pretty well so far. It is basically a hack, given that we do have a proper deployment BOM.

In case of a Gradle project, the deployment dependencies aren't managed at all. This change https://github.com/quarkusio/quarkus/pull/9471/files#diff-47a99fcbc3b7bd6c0498c6fad2a1228aR140 applies platforms enforced on the application (equivalent to Maven's runtime BOM) but is still missing the trick we do in Maven to inject extension versions into the set of the managed dependency versions). TBH, I'm not sure how this can be done in Gradle.

Anyway, I think we do need to use the deployment BOM to resolve the application model (its runtime + deployment dependencies). The natural way would be if the application itself was importing the deployment BOM instead of the runtime BOM. The deployment BOM = runtime BOM + deployment deps. This will also make sure that the runtime classpath is compatible with the deployment dependencies.

Issue #9177 includes a reproducer that can be used to demonstrate the issue. If I build Quarkus master and then quarkus-platform master with the previously built Quarkus master and update the reproducer to use 999-SNAPSHOT, the project won't build due to conflicts in the deployment classpath. A simple workaround would be to use quarkus-universe-bom-deployment instead of quarkus-universe-bom in the project (assuming the change referenced above has been merged into Quarkus master).

[maxandersen]

@aloubyansky what do you want to do with this one ?

i read it again and i'm still not sure which dependency mismatch exactly (or is an example) of the issue; is it not possible to reduce down to a simpler project than a full gradle kotlin based project ?

[aloubyansky]

@aloubyansky what do you want to do with this one ?

As I mentioned in the description, I suggest importing the deployment BOM in the applications.

i read it again and i'm still not sure which dependency mismatch exactly (or is an example) of the issue; is it not possible to reduce down to a simpler project than a full gradle kotlin based project ?

It's possible. Although, as a reproducer it's pretty good enough for now. If you want to reproduce the issue: check it out and build, change the BOM and rebuild.

[aloubyansky]

A simple explanation of this issue would be equivalent to answering the question of what's the purpose of the deployment BOM. If you get that, you should understand what this issue is about.

[maxandersen]

well, I actually thought the reason we did NOT include deployment bom was to avoid having too much included - thus I obviously don't grok what the purpose of deployment vs runtime BOM is for our extensions if you are now suggesting the opposite.

[aloubyansky]

There is definitely a problem, imo, with including too many dependencies into the BOM. In perspective we need a smarter solution, again imo.
Currently though, an application's build classpath may end up being not what we expect it to be and even broken.
We could theoretically be pulling the deployment BOM in the same manner we are pulling in the deployment dependencies, i.e. behind the scenes and applying it when resolving the deployment part of the build. It will in fact be better than what we are doing today even in case of Maven. However, taking into account that the deployment deps are simply added "on top" of the runtime ones, to do it right, I think, the deployment BOM should be managing all the deps (runtime plus deployment). In fact, this is what the deployment BOM includes. It is its purpose.

[aloubyansky]

Here is one of the possible reproducers https://github.com/aloubyansky/playground/tree/quarkus-runtime-bom-insufficiency.
Simply launch build.sh. It'll build all the projects including the app. Which will fail. If you change to the deployment BOM here https://github.com/aloubyansky/playground/blob/quarkus-runtime-bom-insufficiency/acme-app/pom.xml#L16 it'll work.

[aloubyansky]

This is just one of the ways to reproduce it.

[aloubyansky]

With Quarkus 1.6.0.Final unifying quarkus-bom and quarkus-bom-deployment and quarkusio/quarkus-platform#98 this issue is going to be fixed in the platform 1.7.0.Final release.

[lfarkas]

io.quarkus:quarkus-bootstrap-core:2.13.0.Final still not pushed...

[aloubyansky]

Could you clarify what you mean by that @lfarkas? Thanks.

[gsmet]

It's there: https://repo1.maven.org/maven2/io/quarkus/quarkus-bootstrap-core/2.13.0.Final/ .

Use mvn -U to make sure it refreshes the download state.

[lfarkas]

https://mvnrepository.com/artifact/io.quarkus/quarkus-bootstrap-core

[gsmet]

Their index is just not real time. So you have a delay. It is on Maven Central.