ascheman commented on issue #12507:
URL: https://github.com/apache/maven/issues/12507#issuecomment-5035341243
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
#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 (#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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
