tkobayas opened a new issue, #6761:
URL: https://github.com/apache/incubator-kie-drools/issues/6761
# CI Build Failure Analysis: PR #6759
## PR Summary
PR #6759 replaces `root.getPaths()` with `root.getResolvedPaths()` in
`AbstractDroolsAssetsProcessor.java` — a one-line forward-compatibility fix for
Quarkus 3.37.0.CR1 which removes `getPaths()` from `ArchiveRootBuildItem`. The
method `getResolvedPaths()` is already available in the current Quarkus version
(3.27.4).
## Build Failure
All 5 CI matrix jobs fail with the same error:
```
[ERROR] Failed to execute goal
io.quarkus:quarkus-extension-maven-plugin:3.27.4:extension-descriptor (default)
on project drools-quarkus:
Failed to collect dependencies of deployment artifact
org.drools:drools-quarkus-deployment::jar:999-SNAPSHOT
...
Could not transfer artifact
org.drools:drools-quarkus-deployment:pom:999-SNAPSHOT
from/to block-apache-snapshots: Blocked mirror for repositories:
[apache.snapshots]
```
The same error occurs for `drools-quarkus-ruleunits-deployment`.
## Root Cause
The issue is in **`script/ci/CiComputeBuildScopes.java`**, not in the PR's
code change itself.
### How the CI scoped build works
1. `ci.yaml` collects changed files from the PR diff
2. `CiComputeBuildScopes.java` maps changed files to Maven modules, builds a
dependency graph via `dep-graph-extractor`, and computes three sets:
- **changed**: modules whose files were modified (1 module:
`drools-quarkus-util-deployment`)
- **affected**: changed + transitive downstream dependents (12 modules)
- **upstream**: transitive upstream dependencies of affected, minus
affected (63 modules)
3. Two Maven passes run:
- Upstream pass: `mvn install -DskipTests -pl <upstream>` (build
dependencies without testing)
- Affected pass: `mvn install -pl <affected>` (build and test affected
modules)
### The blind spot: Quarkus runtime ↔ deployment pairing
Quarkus extensions consist of two paired modules:
| Runtime module | Deployment module |
|---|---|
| `drools-quarkus` | `drools-quarkus-deployment` |
| `drools-quarkus-ruleunits` | `drools-quarkus-ruleunits-deployment` |
The runtime module does **not** declare a Maven `<dependency>` on its
deployment counterpart. Instead, the link is declared in metadata
(`quarkus-extension.yaml` or plugin configuration). The
`quarkus-extension-maven-plugin:extension-descriptor` goal on the runtime
module resolves the deployment artifact at build time through this metadata —
outside of Maven's dependency graph.
`CiComputeBuildScopes.java` builds its dependency graph from Maven
`<dependency>` relationships only. It does not see the implicit Quarkus
runtime↔deployment link.
### What happens with this PR
```
Changed file:
drools-quarkus-util-deployment/src/.../AbstractDroolsAssetsProcessor.java
Dependency chain (Maven <dependency>):
drools-quarkus-util-deployment
← drools-quarkus-deployment (depends on util-deployment)
← drools-quarkus-ruleunits-deployment (depends on
drools-quarkus-deployment)
Implicit link (Quarkus extension metadata, NOT Maven <dependency>):
drools-quarkus ←--→ drools-quarkus-deployment
drools-quarkus-ruleunits ←--→ drools-quarkus-ruleunits-deployment
```
The CI places the runtime modules (`drools-quarkus`,
`drools-quarkus-ruleunits`) in the **upstream** set because they are upstream
dependencies of other affected modules (e.g., integration tests). The
deployment modules (`drools-quarkus-deployment`,
`drools-quarkus-ruleunits-deployment`) end up in the **affected** set as
downstream dependents of the changed module.
The upstream pass runs first and builds the runtime modules. When Maven
executes `extension-descriptor` on `drools-quarkus`, it tries to resolve
`drools-quarkus-deployment`. But:
- `drools-quarkus-deployment` is **not in the upstream reactor** (it's in
the affected set, built later)
- It is **not in `~/.m2`** (it's a `999-SNAPSHOT` that was never published)
- The **apache.snapshots repository is blocked** by `settings.xml` in CI
Result: resolution failure.
## Possible Fixes
### Option A: Pair runtime and deployment modules in
`CiComputeBuildScopes.java`
Add logic to detect Quarkus extension modules (e.g., by convention: if
`<artifactId>-deployment` exists in the reactor, treat them as paired). When
either half is in the affected/upstream set, include the other half in the same
set.
### Option B: Add `-amd` (also-make-dependents) awareness for Quarkus
metadata
Extend `dep-graph-extractor` to parse `quarkus-extension.yaml` or
`META-INF/quarkus-extension.properties` and inject synthetic dependency edges
between runtime and deployment modules.
### Option C: Convention-based fix in `ci.yaml`
After computing the build scope, add a shell step that scans for Quarkus
extension modules and ensures both halves are in the same build pass.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
