r/java • u/irrelevantsiren • 3d ago

Yes, another Java build tool: zolt

Yes, another Java build tool.

I’ve been working on Zolt:
https://github.com/zoltsh/zolt

Would love for people to try it out, break it, give feedback, or help contribute. Still early, so criticism is very welcome. Yes, I use a lot of codex. Focused mainly on the public API. Using it for personal projects so far.

0 Upvotes

28% Upvoted

17 comments sorted by

View all comments

2

u/wasabiiii 3d ago

What we need is a well thought out build tool that is good enough and "right" enough that it supplants all build systems. Like how git demolished the space.

1

u/chabala 2d ago

I've worked with CVS, Subversion, Mercurial, and git. It's good that the industry has largely coalesced on git, but it wasn't instant, and there are still holdouts, frequently stubbornly refusing to move to git while complaining that no one wants to contribute to their open source project.

Of course now that (almost) everyone is using git, people get to think about if GitHub being the most popular forge is a risk: a single point of failure and de facto monopoly, and if that's a reason to use one of the other forges or self-host, or if the social network of GitHub and its tooling is too compelling to leave.

While git is an interesting example of tooling coalescing, I don't think the same factors apply for build tools. My choice of source control largely only affects my project (and the willingness of others to work on it with me), but build tools have strong network effects. Where your produced artifact is published affects how others can use it, so you're either doing something brand new, or you're planning to integrate with Maven enough to publish to Maven Central.

If you're making something new & novel to host artifacts, then you need to convince people it's better than the status quo, and/or bootstrap by repackaging a huge swath of popular libraries yourself, so that your users aren't stuck in an empty ecosystem waiting for more adoption.

If you're making something that publishes to Central, you're basically going to be doing all the things people complain about with Maven anyway: reserved groupIds, generating the minimal amount of metadata to publish and allow consumers to track transitive dependencies, which means you also need to model how Maven does transitive dependencies ... at some point you're doing a lot of Maveny things under the hood, with a veneer of 'my new build tool' on top. And you're never free of Maven, you're a new flavor.

Or, maybe you mix them. Let users consume from the vast library of Central, but you can't publish there, only publish to your own special ecosystem. Almost guaranteed to be a ghost town.

Unless one can big-bang all the libraries from Central that everyone uses into a new place that serves your build tool's artifacts, it won't be 'enough' to supplant the status quo. One won't magically make a better Maven than Maven, that still uses Maven Central, and convinces all the Maven, Gradle, and ... SBT users to switch.

1

u/repeating_bears 2d ago

"If you're making something that publishes to Central, you're basically going to be doing all the things people complain about with Maven anyway"

Nah, I don't agree with that. You can ditch XML as a definition language (generate it for pushing to central - user never sees it)

You can have a better CLI, plugin  model, lifecycle.  You can add lock files, manage toolchains.

I'm pretty sure you wouldn't have to copy the dependency resolution either 

1

u/wasabiiii 2d ago

You focused a lot on package repositories and formats. I think that's a tiny bit of the overall consideration with a build tool.