gnodet opened a new pull request, #24579:
URL: https://github.com/apache/camel/pull/24579

   ## Summary
   
   Remove the grep-based POM dependency detection and shadow comparison 
infrastructure. Maveniverse Scalpel becomes the sole mechanism for detecting 
modules affected by POM changes.
   
   - Remove grep-based functions (`extractPomDiff`, `detectChangedProperties`, 
`findAffectedModules`, `analyzePomDependencies`) — ~330 lines
   - Remove shadow comparison function and all comparison data collection
   - Simplify PR comment to show Scalpel-detected changes directly (properties, 
managed deps, managed plugins)
   - Show Scalpel failure warning in PR comment when detection is unavailable
   - Update CI-ARCHITECTURE.md to reflect Scalpel-only architecture
   
   ## Background: Why Scalpel-only is ready
   
   The dual grep+Scalpel approach was designed as a gradual migration path:
   1. ✅ **Phase 1**: Add Scalpel alongside grep (April 2026)
   2. ✅ **Phase 2**: Shadow comparison to validate Scalpel across many PRs
   3. **Phase 3**: This PR — switch to Scalpel-only
   
   ### Analysis of all successful builds since Scalpel was introduced
   
   An investigation of all merged PRs since the Scalpel integration (April 
2026) found:
   
   **For parent POM property changes** (the grep approach's target):
   - Scalpel consistently detected all modules that grep found — a **strict 
superset**
   - Scalpel additionally caught modules that grep missed (managed deps without 
explicit `${property}`, plugin versions, BOM imports)
   
   **Known grep limitations resolved by Scalpel:**
   1. Managed dependencies without explicit `<version>` — modules inheriting 
versions via `<dependencyManagement>` without declaring 
`<version>${property}</version>` were missed
   2. Maven plugin version changes — plugin version properties consumed in 
`parent/pom.xml` via `<pluginManagement>` were invisible to child modules
   3. BOM imports — modules using artifacts from a BOM were not linked to the 
BOM version property
   4. Transitive dependency changes — only direct property references were 
detected
   5. Non-property version changes — structural `<dependencyManagement>` edits 
without property substitution were not caught
   
   **For container upgrade PRs** (neither grep nor Scalpel involved):
   - Container versions are stored in Java `.properties` files 
(`test-infra/*/src/main/resources/.../container.properties`), not Maven 
`<properties>` — neither approach detects these
   - Detection relies entirely on **file-path analysis + `-amd` expansion**, 
which works correctly since PR #22514 (April 16, 2026)
   
   ### Historical context: the `src/test` → `src/main` fix
   
   The investigation also uncovered a historical regression. On March 27, 2026, 
the script rewrite introduced a `src/test` directory check for `-amd` 
eligibility. Since test-infra modules only have `src/main` (no `src/test`), 
they were misclassified as "pom-only" and their downstream component modules 
were silently dropped from the CI reactor. ~18 container upgrade PRs merged 
without downstream integration tests between March 27 and April 16, 2026 — 
including the Infinispan 16.2 upgrade (#22316) that later required a revert 
(#22954) due to flaky tests that were never caught by CI. This was fixed in PR 
#22514 by changing the check to `src/main`.
   
   ## Test plan
   
   - [x] Script passes `bash -n` syntax check
   - [ ] CI runs successfully on this PR (the PR itself changes CI files, so 
the `paths-ignore` filter may skip the build — a `/component-test` run or 
manual workflow dispatch can validate)
   - [x] Verified all grep-related functions are fully removed
   - [x] Verified no stale variable references remain
   - [x] Verified CI-ARCHITECTURE.md accurately describes the new architecture
   
   _Claude Code on behalf of gnodet_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
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]

Reply via email to