`${...}` expressions in CLI-supplied plugin parameter values are wiped to empty at CLI parse time (Maven 3 resolves them at mojo configuration)

[ascheman]

Affected versions

Reproduced on both master (4.1.0-SNAPSHOT, 671031e) and maven-4.0.x tip (4.0.0-SNAPSHOT, e1f8234). On 4.0.0-rc-5 the symptom is masked by the launcher bug #11978 (eval → bad substitution), already fixed for rc-6 — this issue is about what happens once Maven actually runs.

Reproduction

Minimal pom-packaging project, then (quoted so the shell passes ${...} literally):

mvn deploy '-DaltDeploymentRepository=test::file://${project.build.directory}/deploy'

• Maven 3.9.16 (deploy-plugin pinned to 3.1.3 via direct goal invocation): resolves the expression, deploys to target/deploy/… ✅
• Maven 4 (same deploy-plugin 3.1.3): the expression evaluates to the empty string → repository URL becomes file:///deploy → Could not transfer artifact … from/to test (file:///deploy): /deploy: Read-only file system ❌

Further probes — all wiped to empty: ${project.build.directory}, ${project.basedir}, and even ${user.dir} (a plain system property).

Analysis

The values are destroyed at CLI parse time, before any project context exists:

• BaseParser.populateUserProperties() interpolates all user-specified -D values against only the other user properties plus the small extraInterpolationSource() paths map — no system properties, no project context (impl/maven-cli/src/main/java/org/apache/maven/cling/invoker/BaseParser.java:441).
• It uses the Interpolator.interpolate(Map, UnaryOperator) convenience overload, which defaults to defaultsToEmpty = true (api/maven-api-core/…/Interpolator.java:51-53), so DefaultInterpolator replaces every unresolvable placeholder with "" (impl/maven-impl/…/model/DefaultInterpolator.java:351-353).
• The later v3-compat PluginParameterExpressionEvaluator would resolve these expressions fine (it merges user + system properties and recursively evaluates embedded ${...}), but it only ever sees the already-emptied value.

This is independent of (and complementary to) the recent launcher quoting fixes: #11978/#11983 fixed the shell layer so ${...} arguments arrive intact in the JVM — the failing IT below passes arguments programmatically via the Verifier (no shell involved) and still shows the wipe. Notably, on rc-5 the launcher bug masked this issue with a loud bad substitution shell error; with the launcher fix shipping in rc-6, users will instead hit this silent empty-substitution first.

The parse-time interpolation itself was introduced deliberately by #2480 ("User properties are not interpolated for paths") to support ${session.topDirectory}/${session.rootDirectory} in -D values — the regression is the destructive defaultsToEmpty=true for every other expression, and the asymmetry with the options interpolation (which does include systemProperties::get in its callback chain, BaseParser.java:178-184).

A minimal fix candidate: pass defaultsToEmpty=false for user-specified properties (leaving unresolved placeholders literal for later mojo-parameter evaluation), possibly plus systemProperties::get in the callback chain. Happy to turn that into a PR.

Impact

A common CI pattern (file-based staging deploy via altDeploymentRepository) breaks, and the failure mode is nasty: no error, Maven silently targets a wrong absolute path (/deploy). maven-assembly-plugin already had to work around this in its ITs (apache/maven-assembly-plugin#1325). Any -D-supplied plugin parameter whose value embeds ${...} is affected, not just deploy.

Test coverage

No existing core IT covers this. I have a failing IT ready to contribute (two cases: ${user.dir} and ${project.build.directory} in a CLI-supplied parameter, asserting Maven 3 semantics via maven-it-plugin-configuration); it fails on current master with expected: <PRE-…-POST> but was: <PRE--POST>. PR follows.

cc @gnodet — given the launcher fix lands in rc-6, this becomes the first user-visible failure mode for the ${...}-in--D pattern there.

[ascheman]

Working on a fix for this (#12515), I hit a design question that's really about the intended behavior here, so raising it on the issue. @gnodet you'll probably have the call.

What the fix did, and why its CI is red. The straightforward fix — stop emptying unresolved ${...} at CLI parse time (defaultsToEmpty=false in BaseParser.populateUserProperties) — makes #12515's IT and the deploy repro pass, but breaks exactly one existing IT across all OS/JDK, MavenITgh11978PlaceholderInCliArgTest:

expected: <-value__end-> but was: <-value_${some.maven.placeholder}_end->

That test (the gh-11978 launcher fix, #11978 / #11983) asserts that an unknown ${...} in a CLI -D value resolves to the empty string; the fix leaves it literal instead.

The underlying Maven 3 → 4 delta. Same scenario across versions (POM <myph>-${test.placeholder}-</myph>, -Dtest.placeholder=value_${some.maven.placeholder}_end, read back via help:effective-pom):

Maven	result
3.9.16	-value_${some.maven.placeholder}_end- (unknown left literal)
3.10.0-rc-1	-value_${some.maven.placeholder}_end- (unknown left literal)
4.0.x-SNAPSHOT	-value__end- (unknown emptied)

Two independent changes are in play:

1. Maven 4 interpolates -D user-property values at CLI parse time (from User properties are not interpolated for paths #2480, for ${session.topDirectory} & co.); Maven 3 left them literal and resolved ${...} later at mojo/model time.
2. When unresolvable, Maven 4 empties the placeholder; Maven 3 left it literal.

This issue is (1)+(2) hitting a project expression: -DaltDeploymentRepository=id::file://${project.build.directory}/x is emptied at parse time (no project yet) → file:///x, where Maven 3 resolved it at deploy-mojo time. Fixing that by not-emptying also reverts (2) globally — which is exactly what #11978 deliberately locks in for genuinely-unknown user placeholders. So the two want opposite things.

The design question: they can't both be satisfied by one flag:

• project/session-context expressions (${project.*}, ${basedir}, ${session.*}) should be preserved at parse time and resolved later at mojo configuration (Maven 3 semantics — this issue), while
• unknown user-property references (${some.maven.placeholder}) should still empty at CLI parse (mvn script eval expands ${...} in CLI arguments #11978).

A scoped fix would leave-literal only the expressions the CLI parser can't classify as user/system/path sources (defer the late/project-context ones), rather than flipping defaultsToEmpty for everything. But whether that's the intended direction — or whether #11978's empty-for-unknown should itself be revisited — is the open question.

I've set #12515 back to draft. Happy to rework along whichever line you prefer; the failing IT and a clean cross-version repro are on the PR.