Manually enforce platform constraints for conditional dependencies in QuarkusComponentVariants

[reaver585]

Addresses #49743

[aloubyansky]

We definitely want some tests for this change. That would basically mean pre-installing two versions of an extension (as part of a test) that is a conditional dependency. And then writing a few tests:

• when the version is enforced
• when the version is not enforced
• when a conditional dependency is excluded by a user

[reaver585]

We definitely want some tests for this change. That would basically mean pre-installing two versions of an extension (as part of a test) that is a conditional dependency. And then writing a few tests:

• when the version is enforced
• when the version is not enforced
• when a conditional dependency is excluded by a user

@aloubyansky should be done now.

[aloubyansky]

@reaver585 this is looking good to me, thanks a lot!
I added a few remarks but they are not blocking this change from merging.

[aloubyansky]

This could happen and we shouldn't fail. I think, what could help is catching these clashes early, when we initialize a PlatformSpec.

For example, there could be multiple artifacts mentioned in the BOM with the same group and artifact IDs but different classifiers and/or types. They could even have the same version. Let's make sure this does not result in an error.

Then, on purpose or not, a BOM (the original Maven POM XML, at least) may include different versions of the same artifact. It doesn't make sense but it may happen. In this case, the first occurrence should be the effective one.

A tricky case would be when org.acme:acme-lib:1.0 and org.acme:acme-lib:some-classifier:2.0 are found among the constraints. Then it's kinda difficult to pick a common version for org.acme:acme-lib.
To avoid that, ideally, we should be using groupId:artifactId:classifier:type when recording constraints and during matching.

[reaver585]

As discussed bilaterally, we are not going to implement such functionality, mapping GA to a list of constraints, because, when we process the platform configuration and its DependencyResultDetails in here, all such DependencyResultDetails are already deduped based on GA. So, multiple constraints for a unique GA aren't exposed to us, despite they are actually declared in Quarkus' platform BOM.

Moreover, neither classifier, nor type, and nor the exludeRules in these processed BOM dependencies.

[reaver585]

@gsmet quick question: do you know if I can access the test reports?

On the previous pipeline run, a test (JVM 25) job failed, GHA logs are definitely not enough, and the uploaded artifacts on the summary page get me an archive (test-reports-JVM Tests - JDK 25) with some dirs but no files at all.

[aloubyansky]

Thanks a lot @reaver585 !

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit c315a0e.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.