Fix #13004: enable deterministic profile activation for BUILD_CONSUMER - #13006
Merged
Conversation
gnodet
force-pushed
the
fix-13004-consumer-pom-builder-fails-on-profile
branch
from
September 1, 2026 22:02
fc32f54 to
1d6cecd
Compare
gnodet
changed the title
…tifactId Add unit tests and integration test verifying that the consumer POM builder correctly handles OS-activated profile properties used in dependency artifactId coordinates. This scenario (from Apache Hop) is already handled by the CONSUMER_PARENT request type (#11799) and the MNG-8709 user-property fix, but had no regression test. Unit tests cover: - BUILD_CONSUMER resolving parent profile properties in artifactId - BUILD_CONSUMER after BUILD_PROJECT (cache hit scenario) - OS-activated profile properties with full reactor simulation Integration test covers: - Multi-module project with OS-activated profiles in parent POM - Dependency management entries inside profiles using ${...} artifactId - Non-flattened consumer POM preserving parent and profiles - Flattened consumer POM fully resolving the property Closes #13004 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The consumer POM builder previously skipped ALL profile activation for
BUILD_CONSUMER requests, which left platform-dependent properties (e.g.
${swt.artifactId} from an OS-activated profile) unresolved. The coordinate
validator then rejected these as invalid artifact IDs.
Enable activation of deterministic profiles — those triggered by JDK
version, operating system, or activeByDefault — for BUILD_CONSUMER, while
continuing to skip file-, property-, and condition-activated profiles.
This mirrors the filtering already applied to repository-resolved models
in PR #12948 (externalOrigin). Repositories from activated profiles are
stripped so they do not leak into the published consumer POM.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
gnodet
force-pushed
the
fix-13004-consumer-pom-builder-fails-on-profile
branch
from
September 2, 2026 05:50
1d6cecd to
6dc97d4
Compare
- DefaultVersionResolver: remove extra blank lines (Spotless) - DefaultVersionRangeResolver: remove unused IOException import (Spotless) - DistributionManagementArtifactRelocationSourceTest: add throws clause for ArtifactDescriptorException after relocatedTarget signature change Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Packaging-activated profiles are handled separately by the consumer POM builder's inlinePackagingActivatedProfiles(), which properly filters non-transitive scoped dependencies. Activating them during model building would double-merge their contributions, leaking test-scoped dependencies into the consumer POM. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
gnodet
marked this pull request as ready for review
September 2, 2026 07:43
gnodet
commented
Sep 2, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
Author
There was a problem hiding this comment.
Clean fix for deterministic profile activation in BUILD_CONSUMER model building. The approach of filtering out property/file/condition-activated profiles during consumer builds — while letting inlinePackagingActivatedProfiles() handle packaging activation separately — is well-reasoned and avoids double-merging.
One low-severity suggestion:
Missing edge-case test for mixed activation: The test POMs each use a single activation type (file, property, condition, or JDK). There's no test for a profile combining e.g. OS activation with property activation. hasFileOrPropertyOrConditionActivation() would correctly filter such a profile (since activation.getProperty() != null returns true), but an explicit test would lock down this corner case.
📋 PR Metadata
| Aspect | Current | Suggested |
|---|---|---|
| Labels | (none) | bug |
| Milestone | 4.0.0-rc-7 |
✅ |
🔀 Backport Status
master but no backport PR was found for:
maven-4.0.x— consumer POMs are a Maven 4 feature, so this bug applies there too
3.9.x and 3.10.x are not affected (no consumer POM support).
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of Guillaume Nodet
gnodet
added a commit
to gnodet/maven
that referenced
this pull request
Sep 2, 2026
rmannibucau
approved these changes
Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
BUILD_CONSUMERrequests, while continuing to skip file-, property-, and condition-activated profileshasFileOrPropertyOrConditionActivation()filter from PR Restrict what a repository-resolved model contributes to the build #12948 (externalOrigin)Problem
When a project uses OS-activated profiles to define properties referenced in dependency coordinate fields (e.g.
${swt.artifactId}), the consumer POM builder fails with a coordinate validation error becauseBUILD_CONSUMERskipped ALL profile activation. This breaks projects like Apache Hop that use platform-specific dependency selection via OS profiles.Approach
The fix applies the same deterministic-only profile filter to
BUILD_CONSUMERthat #12948 applies toexternalOriginmodels — keeping OS/JDK/activeByDefault profiles while excluding file/property/condition-activated ones. This ensures platform-dependent properties are resolved before validation, while keeping the consumer POM reproducible.Based on PR #12948 — rebased on
pr/model-building-master.Test plan
testBuildConsumerActivatesOnlyDeterministicProfiles— JDK profile now activates, file/property/condition profiles still skipped, repositories strippedimpl/maven-impltest suite passes (629 tests)maven-model-buildertest suite passes (175 tests)🤖 Generated with Claude Code