[incubator-kie-drools-6761] Fix CI scoped build for Quarkus extension runtime/deployment pairing

[tkobayas]

• CI scoped build misses Quarkus extension runtime <-> deployment pairing, causing extension-descriptor failures on PRs #6761

Summary

The CI scoped build (CiComputeBuildScopes.java) computes build sets from Maven <dependency> edges only. Quarkus extension runtime modules have an implicit build-time dependency on their -deployment counterpart — the quarkus-extension-maven-plugin:extension-descriptor goal resolves the deployment artifact at compile time — but this link is invisible to Maven's ProjectDependencyGraph.

When a PR changes a shared deployment utility (e.g. drools-quarkus-util-deployment), the deployment modules land in the affected set while their paired runtime modules land in the upstream set. The upstream pass builds the runtime module first, extension-descriptor tries to resolve the deployment artifact, and fails because it's in a different reactor (built later in the affected pass).

This manifests as an intermittent failure — warm Maven cache masks the bug; cold cache exposes it.

Fix

Inject synthetic dependency edges in CiComputeBuildScopes.java for any reactor module pair where <ga> and <ga>-deployment both exist. This makes the existing graph traversal naturally keep both halves in the same build set. No post-processing or invariant changes needed.

The convention-based matching (not filtered to Quarkus-specific modules) is safe: the worst case for a non-extension pair is that both land in the same set, which is conservative, not wrong.

In this repo, exactly 2 pairs match:

• drools-quarkus / drools-quarkus-deployment
• drools-quarkus-ruleunits / drools-quarkus-ruleunits-deployment

Test plan

• jbang script/ci/tests/CiComputeBuildScopesTest.java — all 12 scenarios pass (new scenario 12-quarkus-extension-pairing validates the fix; existing 01-11 unchanged)
• After merging, open a PR that only changes AbstractDroolsAssetsProcessor.java to confirm the scoped build produces affected=14 upstream=61 (instead of affected=12 upstream=63) and CI passes with cold cache

Note: CI on this PR itself is a full build (affected=257) because the changed script/ci/ files map to the root module. The scoped-build fix can only be validated after merge, with a single-file PR.

[tkobayas]

Hi @tiagobento , This PR is to fix CI failure when a PR changes only drools-quarkus-util-deployment/src/.../AbstractDroolsAssetsProcessor.java (#6759).

As the Note: in the PR description says, I couldn't actually verify the effect of this PR because this PR triggers a full build. I verified the fix by merging this fix in my repo (tkobayas)'s main branch and raised a PR (edit only AbstractDroolsAssetsProcessor.java) tkobayas#12 . I confirmed that the error didn't happen in 5 jobs * 3 times run.

Could you review this PR and check whether it's a valid fix? Thanks!

[tiagobento]

Hey @tkobayas, thanks a lot for taking the time to actually improve the dependency graph logic in the partial build mechanism! I have to say I have seen so many errors happen due to this convention of Quarkus'. I'm not sure why they chose to break the configuration-over-convention aspect of Maven itself, it is truly unpredictable.

Your PR looks great, and I approve it.

Just one minor comment: we have in some places specific dependency declarations that aim to solve that problem. E.g.,:

• https://github.com/apache/incubator-kie-drools/blob/main/drools-quarkus-extension/drools-quarkus-examples/drools-quarkus-examples-reactive/pom.xml#L95-L112
• https://github.com/apache/incubator-kie-drools/blob/main/drools-quarkus-extension/drools-quarkus-examples/drools-quarkus-examples-multiunit/pom.xml#L68-L85

I think those two strategies are complimentary to each other, since this PR makes topology sorting include the -deployment modules, while these explicit dependency declarations in the POM put the -deployment modules in the classpath. But I guess it is true that explicitly declaring the -deployment modules makes this PR not have a lot of effect anymore, as normal dependencies are already correctly picked up by the current dependency graph logic.

[tkobayas]

Thanks for the confirmation!