COR-1258: inactive Maven profile sections no longer leak into the base dependency graph - #145
Conversation
…y and dependencyManagement extraction An inactive profile's dependencyManagement (and properties) were parsed from the raw POM before section stripping, so a profile-only managed version could pin a versionless base dependency, and reporting-plugin dependencies surfaced as application dependencies. Strip sections first and feed properties and management extraction from the stripped text. Addresses the two open review findings on PR #142.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
No actionable findings. I verified the merge-base diff and the Maven parser call path: stripping now precedes both property and dependencyManagement extraction, the new inactive-profile fixture covers both leak paths, and the reporting fixture asserts exclusion of the nested reporting dependency (report-helper). The shared section list leaves project-level properties/management behavior covered by the existing Maven fixtures.
Validation: RUSTUP_TOOLCHAIN=stable ./harness test passed all 555 tests; clippy and format checks passed. The PR's Rust test job and completed platform builds are also passing.
Sent by Cursor Automation: pr-flow
corgea-security
left a comment
corgea-security
left a comment
There was a problem hiding this comment.
Automated review risk: 2/5.
No actionable findings. The supplied diff consistently prevents profile, build, and reporting sections from influencing base dependency/property extraction, with targeted regression coverage.
No critical or high-priority changes were found.
corgea-security
left a comment
corgea-security
left a comment
There was a problem hiding this comment.
Approved by Dennis: high policy risk and automated risk 2/5.
3 participants
Summary
Addresses the two open automated-review findings on #142 (review):
dependencyManagementleaked into direct dependencies:split_dependency_managementran on the raw POM before<profiles>were stripped, so a profile-only managed version (e.g.9.9.9) pinned a versionless base dependency. Sections are now stripped first; the dependency stays unresolved instead of taking the inactive profile's version.<reporting>joins<profiles>/<build>in the stripped set.Follow-through from the same reordering:
parse_pom_propertiesnow also reads the stripped text — a profile's<properties>block could previously resolve${...}placeholders in base dependencies (same leak, one line above the fix). Profile-only placeholders now pass through unresolved.NON_DEPENDENCY_SECTIONS) used by bothparse_pom_dependenciesandpom_project_version, so the two lists can't drift.Effective-POM territory (profile activation, parent chains, imported BOMs) stays out of scope, tracked in COR-1733.
Test plan
java-maven-profile-mgmt+ test asserting an inactive profile's managed version does not pin a base dependency and profile-only properties do not resolve base placeholders — verified to fail against the old code (lib@9.9.9) and pass with the fixjava-maven-plugin-depsfixture extended with a<reporting>plugin dependency; exclusion asserted alongside the existing build/profile casescargo test— 555 passed, 0 failed; clippy (strict) and fmt clean