Skip to content

Launch Windows Java build wrappers with an explicit .\ path - #20895

Open
Jonas Flodén (flojon) wants to merge 1 commit into
microsoft:mainfrom
flojon:claude/java-wrapper-cmd-current-dir
Open

Jonas Flodén (flojon) wants to merge 1 commit into
microsoft:mainfrom
flojon:claude/java-wrapper-cmd-current-dir

Conversation

@flojon

Copy link
Copy Markdown
Contributor

Description

Launching a Windows Java build wrapper fails with 'mvnw.cmd' is not recognized as an internal or external command when NoDefaultCurrentDirectoryInExePath=1 is set.

Aspire runs the wrapper as cmd /c call mvnw.cmd ... with the working directory set to the application. cmd.exe only finds a bare name in the working directory while it searches the current directory, and NoDefaultCurrentDirectoryInExePath=1 turns that search off.

This prefixes the relative wrapper path with a . segment (mvnw.cmd becomes .\mvnw.cmd, ..\x becomes .\..\x) so it is always treated as a path. Absolute paths, such as a wrapper on another drive, are left alone. It is fixed in both places that build this command line:

  • WrapperInvocationFor in Aspire.Hosting.Java, used by hosted Java resources
  • JavaAppHostToolchainResolver in Aspire.Cli, used for Java AppHosts

Verification

  • With NoDefaultCurrentDirectoryInExePath=1, cmd /c "call mvnw.cmd -v" fails with the error above and cmd /c "call .\mvnw.cmd -v" starts Maven.
  • Aspire.Hosting.Java.Tests and the JavaAppHostToolchainResolverTests in Aspire.Cli.Tests pass. I updated the five existing expectations that asserted the bare-name form.

Not verified: an end-to-end AppHost run with this change.

Fixes # (issue)

Checklist

  • Is this feature complete?
    • Yes. Ready to ship.
    • No. Follow-up changes expected.
  • Are you including unit tests for the changes and scenario tests if relevant?
    • Yes
    • No
  • Did you add public API?
    • Yes
    • No
  • Does the change make any security assumptions or guarantees?
    • Yes
    • No

🤖 Generated with Claude Code

cmd.exe only finds a bare mvnw.cmd or gradlew.bat in the working
directory while it searches the current directory, and
NoDefaultCurrentDirectoryInExePath=1 turns that search off. Launching
failed with "'mvnw.cmd' is not recognized as an internal or external
command". Prefix the relative wrapper path with "." so it is always
treated as a path, in both the hosted Java resources and the Java
AppHost toolchain resolver.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 20895

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 20895"

@github-actions github-actions Bot added the area-integrations Issues pertaining to Aspire Integrations packages label Oct 10, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-integrations Issues pertaining to Aspire Integrations packages

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant