gnodet opened a new pull request, #2224:
URL: https://github.com/apache/maven-resolver/pull/2224
## Problem
`RepositoryUriUtils.basedir()` treats the Windows drive letter (e.g. `C`) as
a URL scheme, because `protocol()` returns `"C"` for `"C:\\Users\\..."`. The
`if (!protocol.isEmpty())` branch then strips it, producing a drive-relative
path (`\\Users\\...`) instead of an absolute path.
`new File("\\Users\\...").toURI()` resolves that against `new
File(".").getAbsolutePath()`, i.e. the JVM working directory. On Windows GitHub
Actions runners, the working directory is on `D:` while `java.io.tmpdir` is on
`C:`, so a settings.xml
`<localRepository>C:\\Users\\runneradmin\\...\\repo</localRepository>`
round-trips as `D:\\Users\\RUNNER~1\\...\\repo`, causing path comparison
failures.
This is the root cause behind the Windows CI failures in apache/maven#13677
(where `new LocalRepository(settings.getLocalRepository())` goes through this
code path).
## Fix
Two changes in `RepositoryUriUtils`:
1. **`basedir()`**: detect when the "protocol" is a single uppercase letter
(Windows drive letter) and return the URL unchanged instead of stripping it.
2. **`toUri()`**: switch from `new File(basedir(url)).toURI()` to
`Paths.get(basedir(url)).toUri()` so that path parsing is fully lexical and
never involves `File`'s working-directory-relative resolution.
## Test
Added a Windows-only test in `LocalRepositoryTest` that creates a
`LocalRepository` from a plain `C:\\...` path string and asserts the drive
letter is preserved in `getBasePath()`.
- [x] I hereby declare this contribution to be licensed under the Apache
License Version 2.0, January 2004
- [x] I hereby declare that I have filed an Apache Individual Contributor
License Agreement.
--
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]
