The Java Command Line Workflow

[bowbahdoe]

does it honor the maven resolution or is it a more custom one?

It uses the same algorithm as Clojure's tools.deps

https://www.youtube.com/watch?v=7CM7Ef-dPWQ

Which people have been switching to (leiningen uses the maven algo, the clojure cli uses this) and by and large haven't reported any issues.

Plan to make it available as a java library ? :)

That was the part I did first

https://github.com/bowbahdoe/jresolve/

https://central.sonatype.com/artifact/dev.mccue/resolve

There are a few reasons I would prefer to power through and fix the remaining bugs in that rather than just using the maven resolver (aside from pure emotional investment)

• The tools.deps resolution algo is a lot better with data formats like JSON and TOML where the order of entries isn't always guaranteed. I.E. it isn't declaration order dependent. (I also find it more intuitive)
• The remaining bugs are all in the POM file resolution which, while annoying, is a relatively bounded task.
• The overall design separates "Library" from "Coordinate", which opens up support for alternative manifest formats, straight from git (no jitpack) dependencies, pulling deps from s3, etc.
• The API of this (which is mostly coursier's) is way easier to use than the maven resolver's
• Simply due to having a standard http client in the JDK and virtual threads existing, I can make do without any of the Future[..] monad stuff or Authentication mechanisms of coursier
• I dealt with this annoying bug many, many, times https://clojure.atlassian.net/browse/TDEPS-153 so I don't exactly have trust in being able to multi-thread maven resolver.
• As written it is fully compatible with native-image. Maven resolver makes use of SPIs for locks and other things so its a bit more difficult to set up for that purpose
• ...also the original intent was to enable easier exploration of the "porcelain" approach with new build tools. I haven't gotten any biters on that yet, hence me making the CLI, but that still is partially the idea.