[#12288] Pass settings.xml profile properties to LRM#12297
Merged
Conversation
Adds two integration tests asserting that <properties> declared in
a settings.xml <profile> reach the resolver session config before
the LocalRepositoryManager is initialized.
The fixtures use aether.enhancedLocalRepository.{split,localPrefix}
because those have an observable effect on the install path, but the
propagation gap covered by the tests applies to any profile property.
Only the profile's <properties> block is consumed; the profile's
<plugins>, <dependencies>, <repositories>, etc. are not in scope here.
Both settings.xml-only activation channels are covered:
* testActiveByDefaultProfile -- <activation><activeByDefault>true</...
* testActiveProfilesList -- <activeProfiles><activeProfile>...
On unmodified master, testActiveByDefaultProfile is RED (the bug) and
testActiveProfilesList is GREEN (acts as a regression guard for the
channel that already propagates correctly).
DefaultRepositorySystemSessionFactory#getPropertiesFromRequestedProfiles previously only considered CLI-activated profile ids (-P). Profiles activated through settings.xml (<activeProfiles> or <activeByDefault>) were filtered out, so any <properties> they declared were dropped before the resolver session was built. aether.* configuration was the most visible casualty (LRM split/localPrefix etc.), but the gap affects every property declared in such a profile. The fix only touches profile <properties>; other profile content (<plugins>, <dependencies>, <repositories>, ...) is unchanged and keeps flowing through its existing project/build channels. Extend the active-profile-id set with request.getActiveProfiles() and add an isActiveByDefault() branch to the filter. Note: this does not re-implement the full DefaultProfileSelector semantics (e.g. activeByDefault deactivation when other profiles of the same source are active). For the property-propagation use case in scope of #12288 this is sufficient; injecting ProfileSelector here would be a larger refactor in a session-build hot path and is left to a follow-up if needed.
- Replace redundant request.getActiveProfiles() call with inactive profile collection so -P !profileId properly excludes activeByDefault profiles - Rename IT class to MavenITgh12288... following project naming convention
This was referenced Jun 17, 2026
This was referenced Jun 17, 2026
|
@gnodet Please assign appropriate label to PR according to the type of change. |
ascheman
added a commit
that referenced
this pull request
Jun 22, 2026
Backport of the master fix (#12297) and gnodet's review hardening to the maven-3.10.x line. On 3.x, request.getActiveProfiles() already covers both CLI -P and settings.xml <activeProfiles>, so only the <activeByDefault> channel was broken. The activeByDefault filter is guarded against -P !id deactivation per gnodet's review feedback. Cherry-picks could not be applied verbatim due to path and API divergence: * Path: 3.x has maven-core/src/main/java/..., master has impl/maven-core/src/main/java/... * API: 3.x exposes request.getActiveProfiles() / getInactiveProfiles() returning List<String>; master uses request.getProfileActivation().get{Required,Optional}{Active,Inactive} ProfileIds(). The minimal-diff adaptation here only adds the activeByDefault branch and -P !id guard; the existing settings.xml <activeProfiles> propagation is unchanged. Master origin commits: * 3e2c756 ([#12288] fix) * 5785235 (gnodet review hardening) Integration tests live in apache/maven-integration-testing and are addressed in a separate PR. Co-Authored-By: Guillaume Nodet <gnodet@gmail.com>
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.
Fixes #12288.
Supersedes #12291 — preserves the original commits by @ascheman with review fixes applied on top.
Original fix (by @ascheman):
Profiles activated through
settings.xml(<activeProfiles>or<activation><activeByDefault>true</activeByDefault>) had their<properties>block dropped before the resolver session was built, soaether.*configuration declared in such a profile silently failed. The same<properties>on the same<profile>worked when activated via CLI-P.Review fixes applied:
request.getActiveProfiles()call with inactive profile collection, so-P !profileIdproperly excludesactiveByDefaultprofilesMavenITgh12288...following project naming convention