Skip to content

[#12288] Backport: settings.xml activeByDefault profile props to LRM#12333

Open
ascheman wants to merge 1 commit into
apache:maven-3.10.xfrom
aschemaven:12288-backport-310x
Open

[#12288] Backport: settings.xml activeByDefault profile props to LRM#12333
ascheman wants to merge 1 commit into
apache:maven-3.10.xfrom
aschemaven:12288-backport-310x

Conversation

@ascheman

Copy link
Copy Markdown
Contributor

@gnodet — for review (you endorsed this backport in #12288).

Backport of #12297 (merged on master, also backported to maven-4.0.x
via #12299) to the maven-3.10.x maintenance line:

A backport to maven-3.10.x (targeting 3.10.0 / 3.9.17) should be
straightforward — the same DefaultRepositorySystemSessionFactory. getPropertiesFromRequestedProfiles method exists on the 3.x branch.
The activeByDefault property-propagation gap and the missing
deactivation check (-P !id) apply there identically.

What changes (on 3.x)

Adapted minimal-diff (4 net lines added to
DefaultRepositorySystemSessionFactory#getPropertiesFromRequestedProfiles):

  • Adds the <activation><activeByDefault>true</activeByDefault> branch to
    the profile filter — this is the actual gap on 3.x.
  • Adds the -P !id deactivation guard (per the review hardening on
    master, 57852351).

On 3.x, request.getActiveProfiles() already returns CLI -P + settings.xml
<activeProfiles>, so the master fix's additional propagation of those
channels is not needed on this line. Only <activeByDefault> was
broken on 3.10.x.

Why not a verbatim cherry-pick

Path and API divergence between master and 3.10.x prevented a clean
cherry-pick -x:

  • Path: master has impl/maven-core/src/main/java/...; 3.x has
    maven-core/src/main/java/....
  • API: master uses
    request.getProfileActivation().get{Required,Optional}{Active,Inactive}ProfileIds();
    3.x uses request.getActiveProfiles() / getInactiveProfiles() returning
    List<String>.

The commit body explicitly cites the master origin commits
(3e2c7560 and 57852351) for traceability.

Tests

Integration tests for #12288 on the 3.x line live in
apache/maven-integration-testing
and are addressed by a parallel PR there (will reference here once open).
The IT coverage includes:

Locally: mvn -pl maven-core -am clean install — green.

References #12288, #12297, #12298, #12299.

Backport of the master fix (apache#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 ([apache#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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant