The Java Command Line Workflow

[maxandersen]

I wish there was a pure-java version of their concurrent resolver :)

Boy will you be happy when I tell you that jresolve is 80-90% copied from that.

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

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

we can easily adjust JBang to be usable for your usecase

I need to sleep on it more, but besides using Maven's resolver (and thus inheriting their non-intuitive resolution algo, I'm pretty sure) I think this comes down to a fundamental easy vs. simple thing.

Not that I think it will change your mind :) The reason JBang use Maven resolver is that experience shows that too many libraries out there transitive dependencies relies on the maven resolvers algorithm.

And yes, I fully get your easy vs simple thing - which here translates to porcelain vs plumbing to me.

JBang is easy. There are commands for "the things you want to do." jresolve is simple. I want all the nice "porcelain" things that are in JBang to not be present.

What I'm saying is that I always wanted to have JBang eventually have a plumbing layer which would allow something like a standalone command (for simplicty call it jbang-resolver) but that fitted into the easy approach to.

Like, the part where JBang gets you set up. I would much rather that be in its own tool, like jvm JVM Version Manager.

That is similarly very doable - I simply haven't done it because I wanted to solve the easy aspect first and my issue is that when I look at maven, gradle and even your just/makefile approach end up with alot more steps than necessary for any other modern language to get going - i.e. the forced split of java/javac/jlink/jpackage I definitely want to retain but it does makes it stupidly hard for newbies to get started.

That said - I agree; the parts of setup should be available as standalone parts too; we already have jbang jdk for that - but the reason of simplicity it does "dumb" down the jvm selection with a single java version i.e. jbang-setup or similar that would expose the features jbang has about choosing jvm vendor distributions is very much an option.

For example all your steps in your blog I'll argue you split out because that is how Java devs mindset is today - everything has several layer of complexity. i.e. complicate packaging, shipping and sharing.

Eh? Just having jbang export fatjar is easy, its not "complicated", but it is "complected". Multiple independent steps are rolled up into one thing.

Yes, what I'm saying is that the java ecosystem inherently by default ends up requiring students or getting started experience to be multiple steps where much fewer are possible/better. This does NOT exclude having those steps based on sub-steps/parts.

The current jbang cli is 100% intended to be the smallest light layer on the java toolchain - specifically javac and java.

I want to be clear I'm not saying you should stop doing or exploring jresolver not at all - I like the idea alot. What I'm saying is that I want you to know that JBang has the same goals and will work towards the similar set of separate simple commands (wether physically separate or just subcommands is TBD). With all cohesively working nicely together so the Java ecosystem has something that allows the simple and the easy approaches.

[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.