Profile-level properties from a settings.xml-activated profile are dropped before LRM init

[ascheman]

Background

Apache Maven Resolver lets users configure the local repository manager
through aether.* properties. The Maven user manual describes
<properties> inside a <profile> as a regular way to set them, and
the documented activation channels for such a profile are:

• CLI: mvn -P <id>
• settings.xml: <activeProfiles><activeProfile>...</activeProfile></activeProfiles>
• settings.xml: <profile><activation><activeByDefault>true</activeByDefault></activation>...

The first two channels propagate the profile's <properties> to the
resolver session as expected. The third does not.

Bug

When a profile is activated through
<activation><activeByDefault>true</activeByDefault></activation> in
settings.xml, the properties declared in that profile's
<properties> block never reach the
RepositorySystemSession.configProperties that the
EnhancedLocalRepositoryManager reads at initialization. Consequently,
aether.* settings declared in an active-by-default settings.xml
profile have no effect on the LRM — but the same <properties> block
on the same <profile> works correctly when the user activates it via
-P <id> on the CLI, or via <activeProfiles><activeProfile>... in the
same settings.xml.

This is observable to the user because
mvn help:evaluate -Dexpression=aether.enhancedLocalRepository.localPrefix
does report the configured value (the property is in the Maven session
elsewhere), yet the LRM behaves as if no aether.* configuration had
been set.

Reproducer

pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.example.aether</groupId>
  <artifactId>test-artifact</artifactId>
  <version>1.0</version>
  <packaging>pom</packaging>
</project>

settings.xml (active-by-default — broken case):

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0">
  <profiles>
    <profile>
      <id>aether-split-via-settings</id>
      <activation><activeByDefault>true</activeByDefault></activation>
      <properties>
        <aether.enhancedLocalRepository.split>true</aether.enhancedLocalRepository.split>
        <aether.enhancedLocalRepository.localPrefix>mvb-foo</aether.enhancedLocalRepository.localPrefix>
      </properties>
    </profile>
  </profiles>
</settings>

For comparison, the same profile activated via <activeProfiles> (works correctly):

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0">
  <activeProfiles>
    <activeProfile>aether-split-via-settings</activeProfile>
  </activeProfiles>
  <profiles>
    <profile>
      <id>aether-split-via-settings</id>
      <properties>
        <aether.enhancedLocalRepository.split>true</aether.enhancedLocalRepository.split>
        <aether.enhancedLocalRepository.localPrefix>mvb-foo</aether.enhancedLocalRepository.localPrefix>
      </properties>
    </profile>
  </profiles>
</settings>

Run with each settings file:

mvn -s settings.xml -Dmaven.repo.local=$PWD/local-repo install
find local-repo -name 'test-artifact-1.0.pom'

settings.xml activation	Found at
<activeProfiles><activeProfile>... (works)	local-repo/mvb-foo/org/example/aether/test-artifact/1.0/test-artifact-1.0.pom
<activeByDefault>true</activeByDefault> (broken — actual)	local-repo/org/example/aether/test-artifact/1.0/test-artifact-1.0.pom
<activeByDefault>true</activeByDefault> (expected)	local-repo/mvb-foo/org/example/aether/test-artifact/1.0/test-artifact-1.0.pom

Versions

• Maven 4.x master (sha 09fdd6a6, 4.1.0-SNAPSHOT)
• Maven 3.9.16

Likely affects all versions on both lines; backport candidate.

[slawekjaranowski]

It works as expected only <activeProfiles><activeProfile>.. can be used.

https://maven.apache.org/guides/mini/guide-resolver-transport.html#system-level

[ascheman]

Thanks @slawekjaranowski for the documentation pointer — I see now that the limitation was added by you in maven-site#441 / MNG-7850 (July 2023, commit 68861020). Reading the original issue and the PR discussion I cannot find an explicit why — only the observation that profile/activation is not honored at LRM init time. Is there a technical reason (timing / chicken-and-egg with the resolver session build, or otherwise) for the restriction, or is it documented because that's how it happened to behave at the time?

The reason I ask: from a user perspective, declaring an active-by-default profile in settings.xml is the canonical Maven way to "make this always apply"; the requirement to list the profile id a second time in <activeProfiles> is non-obvious. The footgun is double-sharp because the only place this is documented is the resolver-transport mini-guide; settings.xsd and the Maven user guide don't flag the limitation.

The fix in #12291 closes the gap for the <activeByDefault> case at the cost of seven lines in DefaultRepositorySystemSessionFactory. It deliberately does not re-implement full DefaultProfileSelector semantics (so e.g. deactivation-by-other-active-profile is not honored — PR body has the details).

If the conclusion is to keep the existing behavior, would you accept a smaller alternative: emit a WARN when a profile has <activeByDefault>true</activeByDefault> + non-empty <properties> but its id is not in <activeProfiles> / not CLI-activated? I have a local prototype that does that in ~12 lines without behavior change; the warning text points the user directly to the two supported activation channels:

[WARNING] Properties of profile 'aether-split-via-settings' (active-by-default) are NOT propagated
to the resolver session config. To apply them, list the profile id under <activeProfiles> in
settings.xml or activate via -P aether-split-via-settings on the CLI.

Happy to retarget #12291 to that smaller, behavior-preserving variant if preferred. Either way, if you confirm there is a technical reason that should not be unified, I'll close the PR and follow up with a maven-site PR that makes the limitation more discoverable beyond the resolver-transport mini-guide.

[ascheman]

@gnodet @slawekjaranowski — two follow-up questions to round out the issue:

1. Warning for the remaining activation channels?

Earlier in this thread I had offered a warning variant as a behavior-preserving alternative for the <activeByDefault> case:

Would you accept a smaller alternative: emit a WARN when a profile has <activeByDefault>true</activeByDefault> + non-empty <properties> but its id is not in <activeProfiles> / not CLI-activated? I have a local prototype that does that in ~12 lines without behavior change; the warning text points the user directly to the two supported activation channels […]

Now that the fix in #12297 (and the regression-guard follow-up in #12298) handles <activeByDefault> cleanly, the warning is moot for that case. But the four other activation channels (<jdk>, <os>, <property>, <file>) still silently drop their <properties>, because their evaluation happens later in the model builder than the resolver session build.

Would it make sense to emit a single [WARNING] from DefaultRepositorySystemSessionFactory#getPropertiesFromRequestedProfiles when a profile

• declares one of those four activation conditions, and
• has a non-empty <properties> block, and
• is not active via <activeProfiles> / CLI -P

Same shape as the earlier prototype, just scoped to non-activeByDefault activation conditions:

[WARNING] Properties of profile '<id>' (activated via <kind>) are NOT propagated
to the resolver session config. To apply them, list the profile id under
<activeProfiles> in settings.xml or activate via -P <id> on the CLI.

2. Backport to maven 3.9.x?

The same bug reproduces on Maven 3.9.16 (same activation-time-vs-LRM-build-time ordering). For users who can't move to Maven 4 yet, would a backport of #12297 (and whichever shape #1 lands in) be in scope, or is the 3.9.x line strictly maintenance-only at this point?

Happy to prepare the backport PR once you confirm direction.

Why I'm asking together

This affects the maven-site doc clarification I'm drafting at apache/maven-site#1602 — the final wording depends on whether the limitation gets fixed on both lines or only Maven 4, and whether there's a WARN bridging the not-yet-fixed conditions. I'll keep that doc PR as Draft until both questions are settled.

[ascheman]

Can we please reopen the issue and first clarify the open questions, @gnodet?

• Should we get a back-port to M3?
• Should we issue a warning?
• Documentation fix is affected by these decisions.

[gnodet]

This bug also reproduces on Maven 3.9.16 (as confirmed by @ascheman in #12291). The fix has been merged to master via #12297 and backported to maven-4.0.x in #12299.

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.