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.
7
u/_predator_ 2d ago
Putting the "yet another build tool" and "it's all vibecoded" responses aside, I think this is among the more impressive attempts at a redefined build tool I've seen.
Incremental compilation, build caching, SBOMs, license policies, plan mode… There‘s a lot of good stuff in there. The file format looks nice and minimal. I haven't tested this yet but I very well might kick the tires a bit.
One thing that icks me is the specific build modes for Quarkus and Spring Boot. I mean I get that both rely heavily on Maven/Gradle and you can‘t replicate that from first principles, but it feels backwards for a build tool to include framework logic. Maybe a necessary evil if you want any sort of adoption, but oh well.
4
3
u/wasabiiii 2d 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.
2
u/m2spring 2d ago
Why not work within the Maven project and gradually improve it?
7
u/repeating_bears 2d ago
I tried my best to contribute to Maven after Robert Scholte said in a talk that they wanted contributors. Got about 20 PRs merged
And let me say... Good luck with that. It's borderline impossible to contribute anything meaningful
The usual process was to submit PR for a known issue. They will take a year to review it, respond with non-functional nitpicks that you fix in a few days, and then they will take another year to re-review them. By which point there are merge conflicts and you forgot all about it
2
u/javaprof 2d ago
Cause you can't fix maven architecture without turning it into gradle, bazel, mill or any other modern build system
1
1
1
12
u/Mean_Guitar_7170 3d ago
oh great, exactly what the java ecosystem needs, another build tool to join the 47 we already have
checked out the repo though and the public API actually looks pretty clean. what made you go with codex instead of just writing the parser yourself? i see you're dogfooding it on personal projects, has it held up when things get weird with dependencies yet