BOM completeness checks

[ppalaga]

Describe the bug

#26026 seems to suggest that the completeness of the BOM is not checked on a regular basis.

This could perhaps be done during the BOM flattening.

I just found out that quarkus-smallrye-reactive-messaging-kotlin-deployment is also missing. Edit: it is not missing, there is no such module quarkus-smallrye-reactive-messaging-kotlin-deployment. Sorry for the confusion. We should check the completeness of the BOMs anyway.

It is hard to figure out manually whether anything else is missing.

cc @aloubyansky

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

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

No response

Additional information

No response

[quarkus-bot]

/cc @evanchooly

[aloubyansky]

@ppalaga by completeness you mean for every runtime artifact there a deployment artifact is expected to be present in the BOM?

[ppalaga]

by completeness you mean for every runtime artifact there a deployment artifact is expected to be present in the BOM?

Yes, at least.

Maybe other related checks are possible:

• All modules (and their io.quarkus transitives) under extensions directory are managed
• All BOM entries exist in some of the configured remote repos

[aloubyansky]

• All BOM entries exist in some of the configured remote repos

AFAICT, there will pretty much always be some non-existing constraints imported with thirdparty BOMs.

[ppalaga]

AFAICT, there will pretty much always be some non-existing constraints imported with thirdparty BOMs.

Yep, but isn't flattening a good occasion to remove those?

[aloubyansky]

It is. Although it'll increase the build time. We'd have to disable it for most common build-for-dev use-cases. Otherwise our colleagues will hate it.

[gsmet]

Can't we use the same trick we are using for the documentation and the bom descriptor? We would have to adjust the script a bit as for the content but it could work, couldn't it?

Talking about: https://github.com/quarkusio/quarkus/blob/main/update-extension-dependencies.sh .

[gsmet]

/cc @famod

[ppalaga]

It is. Although it'll increase the build time. We'd have to disable it for most common build-for-dev use-cases. Otherwise our colleagues will hate it.

Yes, it does not have to happen on every build. I am just asking for doing it regularly.

[gsmet]

Could we just have a check in the enforcer that makes sure all io.quarkus dependencies don't have a version set? That would then require them to be defined in the BOM (or in a dependency management block in the parent for the independent projects).
My guess is that it would be easy to implement given we already have some additional enforcer rules and fast.