You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit ca6dc05
Browse filesBrowse the repository at this point in the historyBrowse files
* Start fix for #423
Assisted-by: Claude Code:claude-opus-5-5
* Find the Maven local repository like Maven does
Agent mode and -g looked for the Maven local repository in
$M2_HOME/repository, which is the Maven install, and never read
<localRepository> from settings.xml. On Windows they also preferred
HOME over the profile directory Java uses. With any of these, scan -g
found 0 packages, and rollback -g dropped the patch record while the
real local repository stayed patched.
The lookup now follows Maven: MAVEN_REPO_LOCAL, then
-Dmaven.repo.local in MAVEN_ARGS or MAVEN_OPTS, then <localRepository>
in the user settings, then in the install's conf/settings.xml, then
.m2/repository under user.home. user.home honours -Duser.home and is
USERPROFILE on Windows. ${user.home} and ${env.X} expand in settings.
Fixes#423
Assisted-by: Claude Code:claude-opus-5-5
* Pin M2_HOME as the Maven install in crawler tests
The integration test asserted the old $M2_HOME/repository lookup.
It now checks that $M2_HOME/repository is not scanned and that the
install's conf/settings.xml <localRepository> is.
Assisted-by: Claude Code:claude-opus-5-5
* Read settings.xml localRepository as XML
Maven reads a CDATA <localRepository> as its text and decodes
entities, ignores a profile property of the same name, and fixes
user.home before command-line -D flags in MAVEN_ARGS apply. The
lookup now does the same. CLI e2e children also drop MAVEN_OPTS,
MAVEN_ARGS, MAVEN_HOME and M2_HOME so a developer's Maven setup
can't redirect their crawl.
Assisted-by: Claude Code:claude-opus-5-5
* Read Maven settings.xml FIFO-safely
A FIFO planted where settings.xml is expected is now refused instead
of blocking the crawl in open(2), as the crawler architecture test
requires for every crawler read.
Assisted-by: Claude Code:claude-opus-5-5
* Skip comments in settings.xml localRepository
A comment inside <localRepository> in settings.xml was kept as part
of the path, so the crawler fell back to ~/.m2/repository while Maven
used the real local repository. The value is now read as Maven's
parser reads it: comments drop out, entities decode, CDATA is kept
verbatim.
The Maven crawler e2e tests also clear M2_HOME now, so a host Maven
install's settings.xml can't steer tests that pin the repo list.
Assisted-by: Claude Code:claude-opus-5-5
* Make the Maven local-repo tests hermetic and clippy-clean
m2_repo_path_treats_empty_m2_home_as_unset now reads the user's
settings.xml, so a developer whose ~/.m2/settings.xml sets
<localRepository> got a red cargo test. Point HOME/USERPROFILE at an
empty temp dir for that test.
Also drop a format! with no placeholders in local_repo_tests, which
clippy --all-targets flags as useless_format.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Parse MAVEN_OPTS in local-repo tests as the host OS does
Three local_repo_tests put a tempdir path into MAVEN_OPTS/MAVEN_ARGS but
resolved with Os::Unix. Unix-mode split_opts treats backslashes as
escapes, so on Windows `C:\Users\...\Temp\.tmpX` became the
drive-relative `C:Users...`, failed has_root(), and the tests got the
settings or HOME path instead. Resolve with Os::current() so the
options are split the way the host would split them; with only HOME set
the Windows branch falls back to HOME, so expectations are unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments