2026-10-07 tools-deps | Clojure Slack Archive

tools-deps 2026-10-07

lvh 2026-10-07T13:29:15.723629Z

@alexmiller FYI we've noticed recurrences of an old bug (TDEPS-153) in Clojure CLI 1.12.6.1673 (latest). We observed this exception during dependency resolution in CI:

text
java.lang.ClassCastException:
  java.util.HashMap$Node cannot be cast to java.util.HashMap$TreeNode
    at java.util.HashSet.add(...)
    at org.apache.maven.model.validation.DefaultModelValidator.validateId(...)
    at org.apache.maven.model.validation.DefaultModelValidator.validateEffectiveDependency(...)

... which sure sounds familiar 🙂 The https://github.com/clojure/tools.deps/commit/364380eb87c7696114554bbe82ced4c3ec04e06f introduced thread-local Maven systems/sessions. This https://github.com/clojure/tools.deps/commit/fafd50afa2619a0b26f7580cd0fc7c26cac90b5a replaces retrieve-local with retrieve, sharing one context/system/session. I suspect this change to share Maven state across threads have reintroduced exposure to this race. I suspect this change was motivated because upstream supposedly fixed this by moving to a concurrent data structure. https://github.com/apache/maven/issues/11618 describes the same exception. https://github.com/apache/maven/pull/11734 landed in Maven 4’s compatibility module. However, inspecting CLI 1.12.6.1673’s dependencies shows tools.deps 0.31.1646 and maven-model-builder 3.9.16 which does not include the fix. We haven’t reproduced the exception locally despite repeated forced dependency resolution but that's to be expected with this bug. We're internally reverting to -Sthreads 1 as a workaround. I think an immediate fix is "revert the Jul 24 commit" and a long-term fix is "update Maven, then go back to concurrent access". I have no idea how hard the latter is and/or if there are plans to move to Maven 4's API or whatever; I'll leave that up to you.

lvh 2026-10-07T13:30:37.949829Z

cc @samumbach

Alex Miller (Clojure team) 2026-10-07T13:31:04.354549Z

I don't think the revert would help, others were seeing this before that

Alex Miller (Clojure team) 2026-10-07T13:31:39.511339Z

Last I check (couple months), mima was not ready to use the maven 4 resolver yet, so I was waiting for that.

Alex Miller (Clojure team) 2026-10-07T13:32:19.452839Z

That is my plan, and it's one of many things I'm hoping to get back to soon

lvh 2026-10-07T13:35:39.223029Z

ack; alas it looks there are open backport PRs for 3.{9,10}.x but nothing released

lvh 2026-10-07T13:36:30.841149Z

if you're curious: https://github.com/apache/maven/pull/13303 https://github.com/apache/maven/pull/13304

lvh 2026-10-07T13:37:04.556769Z

quite literally approved an hour ago?! so 🤞

👀 1

lvh 2026-10-07T13:48:43.552549Z

I know less than nothing about mima but FWIW it looks like the maven 3 compat layer in 4 makes the tests pass (I ran 'em with "4.0.0-rc-6" and confirmed the actual validIds in the mima model instance is a concurrent hash set, so it's not just a vendored version). clearly updating to an rc maven is hardly a serious suggestion but I am optimistic about this getting fixed; so I think your tack here is probably wise

Alex Miller (Clojure team) 2026-10-07T15:05:26.731549Z

would love a backport

Alex Miller (Clojure team) 2026-10-07T15:06:11.195239Z

maven resolver 4 is a big update, so I have trepidation around making that leap before it's time

lvh 2026-10-07T15:07:04.147389Z

right; there's an api compatibility layer but that says little about behavior; and I have no idea how much Mima tests there

Alex Miller (Clojure team) 2026-10-07T15:07:29.749369Z

a workaround for now is to use -Sthreads 1

Clojurians Log v2

tools-deps 2026-10-07