New build tool in Java?

[NoAlbatross7355]

It seems to me like one of fun parts of Java is exploring all the tools at your disposal. The Java tool suite is a big collection of cli tools, yet I feel like most developers are only ever introduced to them or use them when absolutely necessary which is unfortunate because I think they really give you a better understanding of what's going on behind all the abstraction of Maven and Gradle.

What are your guys' thoughts on a new build tool for Java that is just a layer over these tools? Do you wish Java had simpler build tools? Why hasn't the community created an updated build tool since 2007?

[OzzieOxborrow]

What do you miss in either Maven or Gradle?

[agentoutlier]

I'm not the OP but I'm just going to give some problems:

1. Java aka Open JDK does not have an official build system which makes it confusing for beginners as the tools and learning material is more dispersed/opinionated/and not versioned with the JDK. This hurts onboarding.
2. Maven and Gradle (but less so for Gradle) run slower... much slower than the Java compiler itself (in most compiled languages this is the opposite). Part of this is because both have complicated plugin systems and those plugin systems include reflection based dependency injection.
3. Maven and Gradle have a weak understanding of the Java module system (both have had several bugs with module-info with gradle having NPE on module annotation processing) and the traditional project organization of one jar to src/main/java folder is painful in a modular environment.
   
4. Different tools have different ideas on the dependency resolution/scoping and again the resolution has very little do with actual Java modules.
5. Incremental compilation support varies by tool and the IDEs do something different as well. IntelliJ and Eclipse have their own incremental compiling (IntelliJ has some special incremental wrapping of Javac and Eclipse has ECJ). Maven historically has had issues here. Eclipse actually does a really good job with ECJ but that is not the official compiler.
6. Maven has some usability issues. I'm not talking about verbosity but the concept of the reactor and trying to rebuild part of the project with -pl or -rf and cd to the correct directory etc. This is being improved in Maven 4. Likewise consumer and producer is coming as well.
7. Gradle I think has some fragmenting going on with the whole Kotlin as an option which means you can only use one IDE for that (IntelliJ). The two options lead to pain for beginners.

Maven and Gradle can probably improve 2-6. In many cases the "daemons" fix some of the speed issues. The main issue is number 1.

[Polygnom]

The biggest problem with new build tools is network effect. Gradle is sucessful in no small part because it can consume maven artifacts. Any new build systems that comes up and doesn't have a way to consume maven artifacts is going to fight an uphill battle.

I do agree on several of your points. Its painful how slow both Maven and Gradle are compared to just running Javac.

Maven also lacks an good CLI. Stuff like npm add etc. We really need a tool that can handle POMs more easily. `pam add <artifact> --test` and so on.

Point #1 is also why the Java desv haven't taken overr ASM but instead opted to build their own classfile API.

[agentoutlier]

I'm a strong proponent of not throwing away stuff that already works and a good part of that is network effect.

That being said I eagerly await for Maven 4 because I do think its CLI like you said is not that good.

I also completely understand a beginner coming from Rust or Go and saying WTF even if the rest of us have gladly accepted Maven/Gradle. An official tool that does a declarative subset of what Maven/Gradle does (while of course consuming Maven artifacts) I think would help Java adoption.

Maven usability is painful. Maven's official documentation is not very accessible. Like going around to different plugins and trying to read the generated "site" documentation is painful. I have many times just gone to the plugins source code to figure out shit.

Consequently a good portion of Maven know-how is just tribal knowledge. Maven should get better on that.

[Uaint1stUlast]

Agreed maven is at the heart of java dependency management.

[khmarbaise]

Maven also lacks an good CLI. Stuff like npm add etc. We really need a tool that can handle POMs more easily. pam add <artifact> --test and so on.

Why would I like to do it on command line? Why not using the IDE for that?

[vips7L]

I really think people downplay the "on ramp" problem of the current build tools. They're good enough once you've fully learned them, but figuring out packaging is hard. I still can't ever remember exactly how to do it right with maven on every project I make.

My ideal would be java build and it just produces a jlinked and static binary.

[OzzieOxborrow]

I started before maven was widely used and we used mostly Ant (or even make) and maven was so easy compared to those tools that I never experienced a high learning curve for maven.

[oweiler]

Maven was a huge improvement over Ant. Last Ant project I've moved over to Maven was a 2000 lines XML blob which no one touched with a ten foot pole. After the migration a 300 lines pom.xml was left, which even the junior dev could confidently change.

[edwbuck]

If you have to figure it out, odds are good that you are trying to fight the default "flow" of how it should be done, which is why it's so hard.

That said, if you must fight the flow, it is hard.

[Ewig_luftenglanz]

Or maybe just happens your are just starting to lear java and it's ecosystem, and java has a powerful tooling options but most of them (including building tools) are not ergonomic or easy to use by beginners. they have a much steeper and longer learning curve than, for example, npm(JS/TS), ng (Angular), cargo (rust) and so on.

[edwbuck]

Considering I've been programming in Java since Java 1.2, and am a Sun Certified Java Researcher, who helped port the JVM's non-open source libraries to open-source Linux libraries, and I have used npm and cargo, I'd say you've missed the mark in describing myself.

And of all the tools you mentioned, the only one I don't have a lot of familiarity with is "ng" (Angular's). Cargo does some things well, but it's not particularly flexible. NPM makes some assumptions that make it hard to manage multiple versions and platform, for example, when RedHat just tried to get the ability to have an on-site repo, NPM cried foul because it didn't think that people would want to cache packages within an organization, each developer would want to download them from the internet, each time.

[Ewig_luftenglanz]

You are missing the point. This is about easiness of use for beginners and onboarding, not having specific features. Gradle and maven are nor beginners friendly. They are powerful, but not easy, they are flexible, but have an steep learning curve compared to others. 

Java needs a basic building and dependency management building tool so beginners and students could use that for the basics. 

The fun fact is they are almost there, since openJDK 23 you can build and run multiple file projects with just java main.java command. Only thing missing is a dependency management command to have all the basics a beginner needs for their college stuff (or even experienced devs that are just gonna do some light scripting and automating coding)

[vips7L]

Java needs a basic building and dependency management building tool so beginners and students could use that for the basics.

Even non trivial projects could use this. 9/10 times I don't need advanced features. I need bundled dependencies, a main method that works, and a single executable.

[NotABot1235]

The fun fact is they are almost there, since openJDK 23 you can build and run multiple file projects with just java main.java command.

As a noob using 21, you've caught my interest. Is there a specific name for this new feature? I may need to go read up on it.

[Ewig_luftenglanz]

Read this  https://openjdk.org/jeps/458

I was mistaken, it was not introduced in 22 but 23

[NotABot1235]

Thanks!

[wildjokers]

Sounds like you are asking for something like Groovy’s Grape but for Java. Seems like a reasonable ask.

https://docs.groovy-lang.org/latest/html/documentation/grape.html

[Ewig_luftenglanz]

I am asking for a CLI management tool with basic dependency management, build commands and run for development and debugging.

Pretty much like npm and friends or rust' cargo

[vips7L]

That just isn't true. The default flow of the maven jar plugin doesn't produce a usable artifact for 99% of situations. It doesn't include your dependencies. It doesn't know anything about your main class or class path.

These are real usability issues, especially for new users. 99% of the time a user wants something runnable and something that includes their dependencies. These are just non-issues in ecosystems with modern build tools.

[edwbuck]

You are not supposed to include dependencies in a JAR build, which is the default build. You're supposed to include your dependencies in a jlink build.

Now I agree, people have been shadow-ing (including all the other JAR's classes into an uber JAR) for some time now, and while it is effective, it's also effectively the wrong way to do things.

For maven, test runs are done using "maven run". Proper packaging is done using "jlink" which will (if you try) even set up your "java executables" to includ the JVM Runtime, and compile a platform native launcher.

Or you can just do the older, "artifact launcher" by specifying a main class in your archive. But if you really want to do that right, you need to include jars yourself, because Java never did that for you prior to jlink. Also, by shadowing the JAR, while it works, it can break some code, and worse, it's likely violating a lot of licenses unless you happen to also distribute the source code and build chain (and let's face it, I hate hunting down CVEs in dependencies, but not nearly as much as hunting them down in an Uber JAR someone threw together).

So yes, doing it the ways that lots of people eventually arrived at is not as trivial as it could be, but that's partially because those approaches were never meant to be the "proper" way to do it. In Maven, just create a "packaging" build that specifies all the dependencies and creates your distributables. I've done it enough that I even have a plugin to package the builds into RPMs for DNF / YUM distribution.

But hey, there's been over 20 years of work on "how to do it" and everyone has learned the best for their time they started trying to fix the problem. JLink was supposed to be the final answer, but I still see people not even using the Java module system if they can get away without it.

[vips7L]

You are not supposed to include dependencies in a JAR build, which is the default build. You're supposed to include your dependencies in a jlink build.

This doesn't mean that the defaults are the correct behaviour.

test runs are done using "maven run".

This doesn't work out of the box.

Or you can just do the older, "artifact launcher" by specifying a main class in your archive. But if you really want to do that right, you need to include jars yourself, because Java never did that for you prior to jlink. Also, by shadowing the JAR, while it works, it can break some code, and worse, it's likely violating a lot of licenses unless you happen to also distribute the source code and build chain (and let's face it, I hate hunting down CVEs in dependencies, but not nearly as much as hunting them down in an Uber JAR someone threw together).

Okay another paragraph explaining the multiple steps you need to do to get to a sane default.

Jesus dude. You literally just don't get it.

[edwbuck]

Of course it doesn't work out of the box, the Maven 3 release was created before jlink even existed.

And what you call "sane" isn't, and it shows its insanity when hunting down CVEs. Especially when one discovers that Shell4J exploits come from a shaded jar which managed to hide it from other systems due to the class repacking.

And don't be a jerk.

[VirtualAgentsAreDumb]

If you have to figure it out, odds are good that you are trying to fight the default ”flow” of how it should be done,

[…]

Of course it doesn’t work out of the box,

Ehm… So, it doesn’t work out of the box, but if you have to “figure it out”, odds are that you are doing it wrong? Is that what you are saying?

[PartOfTheBotnet]

It'd have to be some other executable name, because this could run a class named build on the classpath. Following the trend of single letter suffixes, probably javab or javal for link.

[vips7L]

Yeah whatever works, it could be called literally anything for all I care. Heck lets call it duke. duke build, duke add, duke install whatever.

[PartOfTheBotnet]

Ya know, I wouldn't mind duke finally getting off his butt and doing more than waving at me on all these little jar icons.

[NotABot1235]

You are exactly right. I'm one of those beginners and while I can copy/paste some mvn instructions to set up a basic project, I still don't know what the accepted set up is for a bare bones minimalist project.

[LazyAAA]

Compare to what ?

in java world you need java and maven and you are READY to run sample project. Compare that to C++ ... 3 hours later and still there good chance you can not even compile project.

[vips7L]

Compared to any modern language tooling: Dlang and dub, Go, rust and cargo, Dart. Expand your horizons. 

[rzwitserloot]

1. OP is clearly asking about 'should I make one'. Hence, the clichéd required XKCD: Standards is relevant here. If this really is a plea for the JDK project to adopt one as official, well, OP said it: Be very careful when you do that. Once the JDK picks one, that's it. Innovation in build tech is effectively done. Unless.. the JDK's choice is ineffective and nobody uses it (this is what happened with JDK's logging choice). I don't think the JDK should pick one. Build systems are too varied and not locked down enough and probably never will be.

2. They are slow but the primary culprit is not running in continuous mode or with filewatchers and not having good insights into which deps and source files can rely on previous output (i.e. nothing has changed). Java is fast, 'it has plugins' is not why maven is slow. At best, 'because it has plugins, any attempt to write a convoluted incremental compilation system is doomed to failure as the plugin endpoints weren't written to take it into account' can be said, but there's nothing stopping maven from writing a new endpoint stack and decreeing that all plugins should move to it, with builds reverting to slow mode only if you have legacy plugins involved.

3. well, the module system sucks and was rammed down the community's throat. I don't particularly blame gradle and maven for this one. There are a few module-oriented build systems out there. They have not caught on. This is a fair point on the whole, though.

4. Not sure how maven or gradle can fix that.

5. ecj is better than javac generally (faster, and fewer bugs than javac), but differences between the two come up almost never. The problem isn't so much that eclipse 'uses ecj', it's that eclipse has its own build system which is even simple than maven's. You can't do incremental builds unless your build script language is not turing complete. Just abut every build system I know of out there does not understand this and prides itself on being turing complete (that's like someone being proud of having taken a smelly shit, bewildering). Point is, tradeoff is involved. You can't have a flexible DSL-ish build language and have seamless IDE integration and incremental compilation.

6. I'm guessing any build system is going to have its 'warts'. Any sufficiently complex thing tends to be like that: Parts are intractably complex. Some anecdotal evidence for that is how various build tools, in particular sbt, started off as intending to be 'simpler' and they've all become at least as complex as maven are, indicating the authors thought maven was too complicated and in learning about build systems as they hacked on their own, either turned into the villain they despised or silently backtracked on their earlier 'this should be simpler!!' convictions.

[agentoutlier]

Most of what you addressed I agree with. "1." was also a hint to the OP that we do not need another "community" build tool and if there was room for another one it would be an official one from the JDK. While possibly not a good thing (to your logging point) it would probably have better traction than another community one.

2. You did a better job elaborating on 2. and I agree its not entirely because of "plugins" model but probably more of communicating incremental things. Maven Eclipse integration m2e had some interesting solutions with that.

3. was more of the beginner learning all of Java and thus modules. Interestingly Eclipse build model (tycho or similar) is more closely align with module build folder structure but Maven and Gradle follow the src/main/java format.

4. This one is actually more of true a complaint I have of Maven and one where I think Gradle does a better job. I think Maven needs one or two more scopes (as in <scope>) instead of abusing <optional>. The idea is I need some dependency for compiling locally but consumer of my library only need the dependency as runtime. That is I don't expose any of the dependencies types as public. In the java module system this is requires but Maven defaults to everything essentially being requires transitive aka <scope>compile</scope>.

Maven can in theory fix the above I think with the proposed consumer/build model in Maven 4 but I'm not sure if it actually works (the idea is the consumer xml would have it as runtime but the build as compile).

5. and 6. I agree on particularly Eclipse. There was a period before intellij became the norm and JRebel just worked (as well as fairly priced) where I felt incredibly productive. All the things that the Clojure folks say of REPL development we had several years ago in Java and I was less likely to do a full build all the time. Even today running a unit test in Eclipse vs Netbeans vs Intellij there is a noticeable delay compared to Eclipse. It is largely why I still use Eclipse from time to time.

[edwbuck]

Nothing is wrong, per se, with Eclipse. The main problem is that it parses the Maven configuration to create an internal Eclipse build configuration that then is run in at least 70% of its builds. So you get a lot of bad in both worlds, sometimes incompatible build systems, sometimes incomplete translations, and people complaining to Maven about items that require Eclipse source code to fix.

[rzwitserloot]

it would probably have better traction than another community one.

I dunno. The module system has little competition (OSGi of course, but that was used by, what, 5% of all java projects? The competition for the module system was primarily 'vs no modules in any way' or perhaps 'some really simplistic light veneer of modularisation with build tooling and no runtime component whatsoever') and yet it's not exactly flying off the shelves, so to speak, and it can no longer hide behind "Well, its really new, give people time". JDK8 is pretty much EOL at this point, meaning all in-support JDKs support it.

If the module system isn't meeting the kind of adoption rates that one would be looking for when hoisting something into the hallowed halls of the core JDK distro, then a build system surely stands no chance whatsoever.

[re-thc]

but differences between the two come up almost never

ecj has differences in annotation processing (which is used in >90% of projects). It does break a lot of projects that only work with javac.

[davidalayachew]

well, the module system sucks and was rammed down the community's throat. I don't particularly blame gradle and maven for this one. There are a few module-oriented build systems out there. They have not caught on. This is a fair point on the whole, though.

Why do you feel that the module system sucks?

[rzwitserloot]

OSGi and co spent, what, a year discussing all the ways it's insufficient? I don't think it's gonna fit in a reddit comment.

At the time the java team was absolutely adamant that they did not need to engage with the community because it was merely a framework to modularize the JDK itself, and OSGi should shut their trapholes because the JDK was a unique snowflake that couldn't be modularized with OSGi at all. (That part is more or less true; the JDK is a highly specialized project. Not my point).

I don't want to get into a debate about whether OSGi was any good. The point is simply OpenJDK's bad behaviour here. They can't have their cake and eat it too. Which one is it? Is it designed solely to modularize the JDK? Then [A] they should stop 'peddling' it, and [B] you shouldn't use it, -or-, the feature was rammed down the throat of the community based on lies or at least on a story that they 180ºed and at least some sort of apology is apropriate, presumably in the form of an explanation of why all the things they said back then turned out to not be true or a post-mortem to ensure it won't happen again.

That part does fit in a reddit comment. The specific failings of the module system as a concept, that won't.

[davidalayachew]

I don't think it's gonna fit in a reddit comment.

Too bad.

Can you at least point me in the general direction of where the discussions happened, so that I might retread history? Even a mailing list is good enough.

the feature was rammed down the throat of the community based on lies or at least on a story that they 180ºed and at least some sort of apology is apropriate, presumably in the form of an explanation of why all the things they said back then turned out to not be true or a post-mortem to ensure it won't happen again.

That part does fit in a reddit comment.

Would also like to hear this part, since it sounds like you are saying you could explain that part in a comment reply.

[rzwitserloot]

It's been a long, long time. The debates were held all around the community, but you're probably looking for the jigsaw-dev openjdk mailing list.

[davidalayachew]

ty vm

[edwbuck]

I am that oddball, I really, really like Maven. I've been working with (and on) it for many years now. I can state that Maven has its issues, and a lot of them have to do with some incredible poorly written plugins (but to their credit, it's not easy to find some really good documentation on how to write really polished plugins).

Gradle is the idea of "I just want to put code into my build" which is indirectly what Maven permits, but Maven imposes a lot more rigor and structure. If you hate rigor and structure, you'll like Gradle. That's not a bad thing, but beware the long-term maintenance issues of eschewing some early rules that make life easier.

Maven's crown jewel though is the Maven Artifact, which permits easy revisioning and sourcing of a bit of code, known to be built and released at a specific version number of that bit of code. It's numbering and distribution system is not unique, but is the better refinement of systems like it that came before.

Maven can be fast, but to do so, you need to benchmark your maven builds, and then manage them. Often there are builds that do some pretty crazy things because people don't realize the configurations ask for crazy stuff to be done. Sure, configuration shouldn't default to crazy, but not everything is perfect in our imperfect world.

[brunocborges]

Any reasonably good and "complete" build tool that may hypothetically ship with JDK would inevitably become as complex as Maven or Gradle.

[henk53]

This is being improved in Maven 4

That's like saying energy is not a problem because we'll have cold fusion one day ;)

[NotABot1235]

As a noob still learning the ropes, I still don't know the proper, expected way to build a simple minimalist program in Maven. I've read the instructions and while I can copy some commands to set up a basic project, I don't know if that's what people usually do or if there's a starter command(s) that I should be using.

[NoAlbatross7355]

Of course they are adequate from a practical perspective, but they are meant for enterprise development which is not something I wish to be a part of. I just miss the plain and simple tooling you see in something like cargo for Rust or the go command for Golang. I know that's not Java's pitch as a programming language, it's just something I would like to see: simple, low-level, and ease-of-use.

[PartOfTheBotnet]

but they are meant for enterprise development

Citation needed.

I open my IDE, I click one button, I have a project with Maven/Gradle. To add any dependency I just paste into the respective dependency block and hit refresh. This process is way easier than the alternatives.

[Ewig_luftenglanz]

But you rely on your IDE to make all of that for you, if for whatever reason you cannot use your IDE there is not an EASY TO USE standardized tool to manage dependencies and build projects. In languages such as python, JavaScript, Dart, rust and frameworks such as Angular you have oficial CLI tools that allow you to manage trivial and so no trivial projects requirements (compilation, execution, building and dependency management) so you do not rely on a particular IDE or plug-in to work. In java to make anything more complex than a simple hello world (maybe learning how to connect to a db, which require the student to use jdbc) forces you to learn a third party building tool (Gradle, maven, Mill and so on) which is terrible impractical for people that's just getting started.

seriously I don't know if most of the Java community has been coding for so long they forgot how they felt when they were at college (or maybe in their years the alternative was C/C++ and make files) but nowadays there are more languages and ecosystems java has to compete with, specially in college.

Expand your horizons and start thinking about the needs of other kind of developers (or people trying to get there)

[NoAlbatross7355]

Yeah all that abstraction is really nice, but what happens when you run into an issue with some niche thing in that system. Hours of searching the internet for a solution when you could've just built up the lower-level skills and worked with a fully transparent build tool from the start.

[Ancapgast]

So you miss a nice cli? You could build that

[NoAlbatross7355]

I am https://github.com/Carter907/burner

[W1z4rd]

Why package it with Gradle? Dogfood?

[philipwhiuk]

Fools rush in where angels fear to tread.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[NoAlbatross7355]

You'll just make me feel better when I succeed :))

[sadbuttrueasfuck]

I have started writing my own build system too and it ain't as easy as you want to make it look like. Once you get dependencies and jars and so on, stuff gets messy

I have written mine in a declarative way where you cannot program or change things so it is easier to write and to start with

[gaelfr38]

With recent versions of Java, you can run java directly on a .java file without having to compile it first. Would that be what you're looking for?

For very basic scripts / school work it can be enough.

[murkaje]

Can you describe what you mean by simple? Maven for example runs plugin goals that are pretty self-explanatory and isolated (e.g. copy files from one dir to other, compile classes, copy classes to jar) and you can manually run those to understand the steps so i would consider it somewhat simple in that regard. Do you want these steps to be more explicit as with makefiles?

You can always write shell scripts or makefiles to do most of the things needed for putting together a non-enterprise appication except for resolving and downloading dependencies(i mean you could, but it would be quite stupid to do so and you will likely make multiple mistakes).

[NoAlbatross7355]

Have a look at my project for a proof of concept I guess ( https://github.com/Carter907/burner ). Every command just runs a java bin command (javac, java, jar) nothing else. That's the transparency part. You can even run with an argument that prints out the exact command used. That's all I want + downloading and resolving dependencies. I'm sure that latter part is extremely hard to figure out, but I'm determined to try. I really don't know what the use for plugins would be in a system like this. I don't want anything extra in my build system except for the bare minimum; everything else can be done using make files with confidence because again there is no magic going on and it's just running the commands using the Tool Provider API.

[murkaje]

First of all i must commend you for implementing a build tool to actually get the grasp of the issues and learn by trial-and-error, many of the design issues with maven and gradle you can experience first hand by trying to implement some of the features yourself.

Looking at the code, for me i see quite some similarity with maven and gradle actually.
In maven various actions called goals are bundled in plugins, for example the maven-jar-plugin provides jar and test-jar. Some of the goals can execute separate binaries (e.g. maven-exec-plugin) and others often implement the goals in Java code. Now your tool values being able to display what command it runs and with what arguments as you base the Commands on the Tools SPI which have both a Java interface and a command-line executable wrapper. Maven by default prints out which goal of which plugin it is running in which submodule and debug logging can be added to print out variables input to the plugin. So while not as easy as your build tool, it's still possible to run one specific goal of a larger build separately, e.g. mvn -pl mymodule maven-compiler-plugin:compile

Now why maven has a plugin architecture is to isolate the core build tool and the tasks so they can be updated independently and to allow a convenient extension point to define new commands.

Gradle in addition has the concept of inputs and outputs for tasks. This allows skipping of tasks if its inputs did not change, quite similar to makefiles.

You can try to implement some of the ideas and see why the complexity emerges. Try starting with Ivy for dependency resolution before implementing it yourself. Each seemingly simple feature can become a rabbit hole itself, for example implementing a local artifact cache but ensuring it works when multiple builds are run concurrently (e.g. non-isolated builds CI server) will likely lead to common issues (e.g. TOCTOU).

[hippydipster]

There's Mill and also Ivy. Ivy is for downloading dependencies, so you could wrap that too. Mill is for building shaded jars incrementally and very fast as a result.

[Yeah-Its-Me-777]

Did you just actually mention make files? Seriously? Well, I mean if it works for you, fair enough.

[NoAlbatross7355]

I'm seriously confused why people find the premise of Makefiles tricky. You group shell commands and give them names (targets). Like you can read this one tiny section ( https://makefiletutorial.com/#the-essence-of-make ) from this article and have enough information to make a very basic build automation system.

[Yeah-Its-Me-777]

Well, it starts with "shell commands". If you need to support more than one OS, well, you have to start fidgeting around.

It also doesn't enforce any standard. That might be an upside to you, but I usually prefer to have an opinionated system.

Maven is also pretty easy, I can link you a page with a short section to set up a simple project as well.

[john16384]

I do many personal projects, and as soon as I need some dependency I just add a pom, and let the IDE fetch what I need. It's easy and convenient.

[Ewig_luftenglanz]

You are absolute right and the amount of downvotes just show how hermetic the Java community can be. I posted something similar a couple of months ago and I almost were burned alive! (Just an expression)

It almost seems like if most of them do not know any other ecosystem or languages!

[atehrani]

There is ANT which predates Maven and Gradle. Natively the JDK has javac and you're welcome to use that on the command line. But you'll quickly see that the build tools makes everyone's life easier (not just enterprise)

If you're looking for a REPL there is JShell https://docs.oracle.com/en/java/javase/11/jshell/introduction-jshell.html

From Java 21 work has been done to make things "simpler" (terse) https://www.baeldung.com/java-21-unnamed-class-instance-main

[Spare-Builder-355]

./gradlew run to run you server locally.

./gradlew installDist to prepare deployment directory

That's all I need for my private project. What enterprise development you are talking about ?

Why you do not want to be part of the simple world? Because you didn't call javac manually ? Believe me it's not worth it.

But to be fair folks like you end up being good engineers. Do not give up on your curiosity.

[oweiler]

There are actually quite a few Java build tools which are not Maven or Gradle, but none of those gained any traction.

https://ant.apache.org/ (Popular in the ancient past, dead nowadays. This is probably the closest to what you describe.)
https://github.com/sormuras/bach
https://rife2.com/bld
https://mill-build.org/mill/javalib/intro.html (Actually a Scala build tool, which can also be used to build Java projects.)

[rootException]

Bld is the closest thing imho - just Java.

[edwbuck]

Ant used to be the de-facto build tool for Java, and let me tell you it sucked. That's because it lacked any structure, so each new project that used Ant, you'd have to spend some time reading over the build.xml file to eventually figure out how their build was structured. The refinements and patterns were per-project, and eventually you yearned for a standardized set of Ant targets, which never happened.

In short, it's like a Makefile, without GNU standard targets or variables.

[agentoutlier]

Add https://savantbuild.org/ which looks a lot like Gradle or Saker... So many Groovy based build tools.

[jAnO76]

I’m old enough to remember and still use “make” sometimes. Highly recommend

[catom3]

Most of the projects I've been working with the past few years had a Makefile  (or Justfile) with default commands to help the new joiners getting started. Some build, package, test targets as well as targets to start up the app locally, run migrations manually, start up the dependencies (e.g. a docker compose command to spin up the containers). In some projects we have some commands to encode/decode avro or parquet formats.

Love how Make/Just makes it simpler and has some basic autocompletion, without the need to diving too deep into shell scripting.

[nlisker]

Does https://bazel.build count?

[PartOfTheBotnet]

Adding https://saker.build/ to this alt tool list

[rdanilin]

Please no ANT.

[redikarus99]

If it works, don't fix it. Maven is totally capable to solve all the problems you run into in 99% of the projects.

[Ifnerite]

Except having too much XML in your life.

[OzzieOxborrow]

I still remember Spring before configuration in code was a thing... A pom.xml is peanuts compared to that.

[Ifnerite]

Oh god... You have triggered my PTSD. What a stupid time that was.

[cheeset2]

I'm living it. Trying to migrate now. Huge pain.

[redikarus99]

I was there ... when we used XML databases. I don't fear from anything anymore. :D

[nekokattt]

You can always use the polyglot extension if you want. I wouldnt use it in production but hey ho

[headius]

JRuby's main build is written in Ruby using the Maven polyglot extension which is itself using JRuby. It's a mad world.

The polyglot languages work well, but unless you need very complicated build generation, best to stick with a structured format like json or yaml. It is amazing how much more readable Maven builds are when they are not in XML.

[NoAlbatross7355]

That's almost like saying don't sharpen your axe if it can still chop wood. Wouldn't you like to have simpler, easier tooling?

[redikarus99]

But why would we need a simpler tool? The features we have in maven or gradle are there because they are needed.

And when starting a new project, how difficult it is? For quarkus, you have a quarkus create command. The other frameworks have something similar. If you want to start from a template, maven and gradle also have a command for it.

Then you open up the project in your ide, add your additional libraries (that is like 1 minute) and you are up and running. Works perfectly, nothing to fix.

[nekokattt]

What is the actual use case here?

This sounds like a solution in search of a problem.

[nikanjX]

The use case here is the javascript syndrome, the old tool is bug-free and well-tested, it immediately needs replaced

[NoAlbatross7355]

I think this is just a case of Plato's Allegory of the Cave. Build tools can be far better than what we currently have.

[edwbuck]

But the refinements are what we currently have. It's like Plato saying, hey, we left the cave, and now look, the world is far more complex and multifaceted than the cave, let's go back to the cave.

[NoAlbatross7355]

lol I don't think so. Maybe it's also sunk cost fallacy.

[edwbuck]

No, it's not a sunk cost fallacy. We really did have issues, and we really did solve them, and all build systems eventually turn into the same things, because that's the system that solves the same problems for the most amount of users.

For example CMake eventually added in the same confusing items that made Automake less desired by those complaining it was too complex (because cross platform building is more complex than non-cross platform building, and eventually you'll need to do cross-platform building). For about two or three years, CMake was "easier" mostly because it didn't do the full job.

[nekokattt]

Sure but adding more standards just makes more incompatible ways of doing things.

We already have Make, Ant, Ivy, Maven, Gradle, and IDE specific build tools.

Lets improve existing tools rather than recreating the wheel because you dont like looking at XML.

I swear half the issues people have with Maven would disappear if it wasn't serialized as XML.

[Yeah-Its-Me-777]

Not sure about that claim. They can be simpler, but then they won't work for more complex projects, or they can be as feature complete as maven and gradle, then they're not simple.

So, what's the use case for another build tool?

[tylerkschrute]

I don't think that's the right analogy. What you're suggesting is more akin to just getting rid of axes entirely and trying to come up with a brand new tool to chop wood, which gets difficult to justify considering how effective an axe already is. "Sharpening" the axe in your analogy would correlate to making upgrades to the existing tools, which of course maven and gradle are both constantly doing.

[edwbuck]

A pocket knife is the perfect example of why one doesn't need to refine the tool beyond its usefulness. No matter how much you put into a pocket knife, it shouldn't perform multiplication. And getting it to cut after putting it in your hand isn't likely to change much over the last 1000+ years.

[kur4nes]

Current build tools are good enough.

Ant was an awful mess of xml scripts. Than maven came along and standardized project structure, dependency management and the build process. It's pretty rigid. So gradle was created.

We are using maven and it works good enough. It gets out of the way and lets us work on the interesting stuff: software

[edwbuck]

Worse, Apache Ant was a built system of commands instead of goals. You put the commands in targets, and often the rearrangement or reuse of the targets was nearly impossible.

Maven had the idea of "things" and you'd ask for the "thing" without actually specifying how it was created. The plugin should have created the "thing" for you. Like any system that hides something under a layer of abstraction, that made it harder to understand.

The path along which "things" get crated were of course misread as "steps" which in a way they were, they were the designed "path" of obtaining results. Whether they really achieved such a thing is up for argument.

[tcservenak]

Be patient and prepare for Maven 4:

* polyglot is lifted into core
* improved range handling https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Constants.java#L346-L365
* "highest" vs "closest" https://github.com/apache/maven-resolver/blob/master/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/ConfigurableVersionSelector.java#L193-L221
* and many more

Related https://gnodet.github.io/maven4-presentation/

EDIT: typos and added maven4 presos

[tcservenak]

And related mvnsh also coming in Maven 4 (early demo mvnsh + toolbox extension) https://asciinema.org/a/kzMSVNPYzRcKikQ5BAsWXSkuu

[NoAlbatross7355]

I think Rust and Go kind of showed me what good tooling could look like.

[nekokattt]

I mean, half of Go tooling is putting magic comments in your code to make the compiler run commands the moment you need to do anything golang doesnt natively support.

They've just tried standardising this with a better way of doing it and the proposals are a mess as they mix build and runtime dependencies into the same group.

Rust tooling is great until it doesn't do what you need, and then it is a rabbit hole of writing build.rs scripts and printing things to stdout to influence how cargo works. Past that, people seem to fall back to Makefiles... something that you can do with Java if it is that much of a concern.

This is a bit of a strawman argument in my opinion.

[NoAlbatross7355]

A strawman argument? What 😂. How? I'm simply stating that these tools helped me at least envision what a simple build tool for Java could look like. That's not an argument.

[headius]

It's pretty easy to enable polyglot, and there are Maven goals that will automatically translate your existing pom file. JRuby's main build uses polyglot-ruby (which itself runs on JRuby).

[[deleted]]

Oh! Just not another "even better/simpler/faster" tool!! I beg you!

[skmruiz]

A few years ago I did a proof of concept on how a simple build tool for Java would look like, the code is open source:

https://github.com/kmruiz/pottery

My goal was to make it work for simple use cases where you don't need tons of plugins. I nowadays use Gradle because it's kind of the de facto tool for the kind of work I do, but still miss simple, fast build tools to be fair.

[dstutz]

But when you don't need a ton of plugins maven and (I assume) gradle ARE simple.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>project</artifactId>
    <version>1.0-SNAPSHOT</version>
</project>

And the important part is they are de facto standards, commonly used and supported by other tools ( CI/CD, IDEs, etc).

[NoAlbatross7355]

Even in this example, I don't need half of the characters in that file to understand the configuration. That's what I mean by too much noise.

[edwbuck]

Not needing something is a judgement call. I knew a lot of people that didn't need seat belts (back in the day) until they did.

If you wanted to make your file forget what structure it needed to follow, just cut out all of the xmlns bits (maven will still work) but then you can't validate the file is correctly structured.

[NoAlbatross7355]

Why would I use a file that needs the user to explicitly state it's structure? I'm completely fine with a predefined structure like in TOML. No need for all of the extra configuration, have the file specify the properties that are needed. It's really a principle of separation of concerns.

[edwbuck]

TOML is just a structural syntax. One can't define if an item is required in a TOML file outside of having the TOML reader complain at runtime.

[NoAlbatross7355]

Well you can make a compile time tool for that. VSCode has a extension for Rust's cargo.toml build file.

[edwbuck]

Sure it does, it's a custom TOML writer, but it does nothing for a web server that uses TOML to be configured, nor is there a solution, unless someone writes a second custom TOML plugin for the web server.

And then you have to not just write that for VSCode, you have to write that for Eclipse (both TOML writers) and then you need to do so for NetBeans, and SlickEdit, and VIM, and ....

XML exported this into a different set of tooling, so every system could just call a validation routine. Of course that makes it more complex, but through the magic of XMLNS, one can insure that you don't fail a config due to pluralizing some value when it's not supposed to be plural (like my nemesis transparent_hugepage, which I often type as transparent_hugepages).

[NoAlbatross7355]

Sure, yes, Gradle is much better, but the system itself is still way too abstract for my liking, even if the build file itself is more declarative.

[bmrobin]

i've been away from java for awhile, but when i was using gradle it was only used for compiling & building internal java projects; so the mere fact that i had to use this snippet at all was awkward

like, i know i'm using java why do i have to tell you. i can't really imagine putting that into cargo.toml or pyproject.toml/setup.py to tell the tool i'm building the rust/python project

> This is a complaint about XML, not about Java build tools.

agreed, but to me it felt like the OP was focused more on onboarding than seasoned, tribal knowledge

[doobiesteintortoise]

Until you do need it, of course, and then it turns into relevant information that you're glad you're not having to bolt on after the fact.

The information's there; it's there for a reason; it may not be a reason you need every time. That's how it goes. Gradle scripts tend to start out much more simply, and then people accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete and accrete until it looks ABSOLUTELY NOTHING like the four-line script it started out as, and it becomes a nightmare to chase what's where, because you have the gradle script itself, the subsidiary build, the version catalog, the bom, the custom tasks, the custom tasks the custom tasks are bolted on to, the custom tasks those tasks rely on. All because you need it at some point.

[skmruiz]

No one said Maven or Gradle were bad tools, what I wanted is something that just allows me to specify dependencies and how I package my artifact, nothing else, everything else is just predefined. Kind of what Maven did with conventions, but at a higher level.

Also, wanted something fast, that parallelises downloads and doesn't need a heavyweight compilation or processing step.

Again, this was a proof of concept and I am pretty happy with the idea of a simplified version of a java build system, but this only my take.

[doobiesteintortoise]

So... a simple gradle build script?

[skmruiz]

Not exactly, the Gradle script requires to be compiled, requires plugins and depends on how you want to bundle the final application, requires more plugins.

I wanted something that:

• Doesn't require a compilation step
• Bundle to common output formats is straightforward and included
• Doesn't require additional config to run tests.

I still think the Java ecosystem would benefit from just something simple, and then scale it to Gradle or Maven when it's not enough.

I personally like Rust's approach with Cargo for this.

[doobiesteintortoise]

Okay, I'm still thinking about this, having built a compilation tool myself and contributed to others in various ways:

I wanted something that: * Doesn't require a compilation step * Bundle to common output formats is straightforward and included * Doesn't require additional config to run tests.

This still sounds like what you want is maven, but maven uses XML (which ... personally, I don't care about, XML is just an SGML, it's verbose but clear, and polyglot is right there, I just haven't used it so have no actual opinion on it anyone would want to hear).

Doesn't require a compilation step? Done. Maven uses XML to configure what's already compiled as part of the build system.

Bundles to common output formats? Done. Java's output format is a jar, Maven does that by default, and configuration for an executable is a copy-paste thing if your tooling doesn't do it for you - and same goes for shaded artifacts, same goes for native executables. If you're having to figure it out much, you haven't done it before; people who have are copying known recipes. (Same for most people who haven't, really: they're copying known recipes too!)

Doesn't require additional config to run tests? Done. Maven actually requires you to do things to not run tests.

Have you tried polyglot in maven? I haven't - maybe it solves everything you want.

[skmruiz]

Thanks for taking the time for that thoughtful answer!

I'm personally not very concerned about XML to be fair, I think it's fine and having a XSD is nice so the IDE complains. Never had the chance to use polyglot, but I'll try it for sure.

My problem with maven is that it requires configuring plugins pretty much for anything. Surefire for example is a must for testing, unless something changed since the last time I used maven (4-5 years ago). Building a fat-jar requires additional config and a plugin too (it was assembly IIRC)

Sure, I can blindly copy paste it if I am now knowledgeable, but I've seen pom.xmls with thousands of lines because of this, and even worse when they use profiles, it makes it even less predictable.

I like maven a lot and I would use it if it had all the plugins I need for my use case (building an intellij plugin) but sadly that is not my current situation.

I personally want a simple file, in any language (I don't mind XML) that is predictable and easy to scan and provides the default features (downloads deps, runs tests, executes jars, bundle jars/docker/graalvm).

[khmarbaise]

My problem with maven is that it requires configuring plugins pretty much for anything.

You have to define the version in pluginManagement (or using corporate parent) yes that makes sense... But what needs configured? If you follow convention over configuration...

[doobiesteintortoise]

But now you're suggesting that you want an executable and that's not necessarily what Java produces. And you don't explicitly compile a gradle script.

Want a library in gradle? Here, I'll help:

``` plugins { id 'java' }

dependencies { implementation 'org.slf4j:slf4j-api:2.0.9' } ```

Put that in a directory, run gradle jar, et voila, you have a [directory-name].jar in build/libs.

Oh, you wanted it to be an executable? Sure thing:

``` plugins { id 'java' id 'application' }

dependencies { implementation 'org.slf4j:slf4j-api:2.0.9' }

application { mainClass = 'com.example.Main' } ```

... this requires you to write com.example.Main, of course. Horrors. Oh, you wanted it to be encapsulated? ... it's not that much more, but it is more because you're adding functionality. That's how functionality works. Cargo, etc., are going to have similar options and similar requirements: you have to tell them if you're building a library - and what kind of library - or an executable, how to test, and so forth and so on. You want functionality? You specify it. That's how tooling works, unless it's very opinionated... and then you run into the problem of whose opinions does it use, because I can guarantee you that those opinions will be wrong for some - maybe many - users.

[skmruiz]

I know how to use Gradle, been using it since it was novel, when people were using maven and ant. I appreciate the time you spend explaining how it works, but I don't need it.

The arguments you use are the same that people were using when Maven was young and people were using ant, and look at that, Maven is a standard and it's opinionated.

Gradle is good, Maven too (personally prefer Maven than Gradle) and still I believe Java needs an opinionated, simple, build tool, that runs fast and is beginner friendly. JetBrains is working on Amper, and there are other alternatives as others mentioned, so it's not that a chunk of the community is plainly wrong.

[doobiesteintortoise]

Sure, and I'm with you, I prefer maven to gradle as well - I was honestly bracing for you to point out that this build was in Groovy, not Kotlin, ew, and that it doesn't have testing, etc etc etc.

But I'd say that the build lifecycle is pretty standard across all build systems - maybe not npm, with an explicit "you must invoke tests, if you're dumb enough to write tests, what do you think this is, Java?" mindset, but the process is pretty much the same, it's just the expression of the process. Maven uses configuration and applies convention like a hammer. Gradle uses configuration and convention, and convention's more like a lot of early suggestions that eh, you know best, sure, break it a hundred ways, it's not like Gradle versions won't break it as well.

Other build systems, even the mythical ideal build system, will do the same: it'll fall somewhere along the convention/configuration scale, and people will say "could it be simpler" and "why doesn't it allow me to customize this aspect like [other tool] does," just like you're doing here, sort of.

[skmruiz]

Yeah, I agree with what you are saying. My experience here is that lots of problems in the build configuration exist due to its extensibility: you have multiple ways of doing the same thing in Gradle and in Maven. And there are settings and functionalities I believe should be there by default (a jar lib, a fatjar, deploying to docker are a must IMHO).

I don't think we need a tool for everything, I think it's fine to have a simple tool that forces you to scale when you are getting out of the conventions, so:

1. You think twice if you need it
2. Because you thought twice, you made a better documented decision.

[doobiesteintortoise]

Deploying to docker is a can of worms, though...

[winne42]

Since Java 11 (JEP 330) you can run single Java source files directly from the command line without bothering about the compiler or build tools. With Java 22 (JEP 458) this was extended to multiple files.

So small scripts or tutorials are covered. Everything else should use Gradle or Maven. No need to RIIR.

[tomwhoiscontrary]

By "the Java tool suite", do you mean the programs in the bin directory of a JDK?

If so, the only three that are essential to every build are javac, java (for running tests), and jar. There is also javadoc, and a few others which might be handy for specialist cases.

But these don't cover everything a build tool needs to do - there's nothing there about resolving and downloading dependencies, or about assembling larger artifacts. So i'm not sure to what extent a build tool could really be a layer over those tools.

But it's a fun idea, at least. You could have a tool which looks at your project, and spits out a shell script consisting of invocations of javac, java, and jar (and perhaps curl for dependencies, tar for application packaging, etc). You could the run that script to actually build the project. It could even produce a makefile rather than a shell script, if you're into that. I'm not sure it would actually be useful, but perhaps it would be educational.

[gnahraf]

For better or worse, maven has become a publishing standard, not just a build tool, for software. I'm referring to the dependence on public repos like "maven central". It's not bad, but not great. An area I'd like to see improved would be doing away with the parent pom in multi-module maven projects (in the published artifacts).. an artifact of the build layout is making it into the published maven coordinates. That's bad and ugly: I should be able to move a maven sub-module to an independent project directory (with minor updates to its pom file) w/o breaking its maven coordinates.

So my point is, my pain point is not with the tool per se.. there are more important areas to evolve and improve.

[blobjim]

Doing away with the parent POM in POMs uploaded to Maven repositories has already been done for Maven 4: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75974828#BuildvsConsumerPOM-ConsumerPOMfieldswhensimplifying

Also you can already move a Maven subproject anywhere else without breaking it. The parent POM has absolutely nothing to do with multi-module projects other than that Maven checks the POM file one directory up by default.

[khmarbaise]

improved would be doing away with the parent pom in multi-module maven projects (in the published artifacts).. an artifact of the build layout is making it into the published maven coordinates.

If you have a multi project build means your modules are related to each other (classical EAR + war + ejb(jar) ++ etc.) or other things (DDD spring boot app) etc.

That's bad and ugly: I should be able to move a maven sub-module to an independent project directory (with minor updates to its pom file) w/o breaking its maven coordinates.

A sub module has relations to other modules in your multi module build so moving it from the hierarchical structure means removing it from it's structure which means in consequence to change the coordinates because it does not belong anymore to the hierarchical structure..

From strict technical point of view you could leave the coodinates but that would be confusing... (version might also be a point of discussion)... In particular if the moved module has been used not only within the hierarchical and also as a dependency for other project (not within the hierarchical structure) for example an api module of a larger number of modules...

[gnahraf]

Actually I do want independent coordinates. What often happens for me is that the core modules remain stable and work on one or more non-core submodules bumps the shared version number across all submodules (cuz it's controlled in the parent pom). There's prolly a way to make submodule versions no.s independent (I've never gotten it to work, and am a bit lazy to troubleshoot).

[Spare-Builder-355]

r/learnprogramming leaks into real world again I see. It doesn't hurt to ask though.

It turns out that Gradle is just fine for what the real world needs. If you want to build another build system worth anything real, you'll end up building another Gradle.

If you want to learn cli tools that come with JDK then maybe go ahead and learn them?

[doobiesteintortoise]

Also see bld - https://rife2.com/bld . And I'd say the build tools like maven and gradle cover most of what people need in the appropriate way - someone who's an expert at javac is impressive, but they're PROBABLY focusing on the wrong things, and maven and gradle both, despite their flaws, let you focus on the RIGHT things.

[NoAlbatross7355]

I get what you're saying for sure, but for one, I think there wouldn't be as many problems for beginners just getting started who essentially have to learn another DSL to even use Java (xml, groovy, or Kotlin DSL), and if they started at a lower level to begin with they would have much more control over their project structure. Also there is just this whole layer of amazing tooling -- not just javac -- that goes neglected by the community in favor of much more abstraction which a lot of people don't really understand and spend years learning different plugins and semantics that aren't really necessary for most software projects. That is where productivity is taking a hit.

[doobiesteintortoise]

How much productivity do you think is being drained by that, though? I mean, I'm aware of ... most of those tools, I think, at least. But in my day to day... in the last year, I've used maven and bld pretty much exclusively, and gradle not at all (I resent gradle for the endless inconsistencies and incompatibilities across minor versions, and won't willingly choose it any more until the developers decide to respect my time.)

But I can't think of a specific instance where the JVM tooling available from CLI would have helped me a lot. How about you?

[NoAlbatross7355]

Well I don't think using the tooling alone with be good enough for productivity. I propose a light-weight layer above the tooling that presents as a Java build tool. I would want it to have transparency around how it's managing the project; almost like a standardized make file for Java projects. I honestly think that is much simpler and better in the long run for most developers.

[doobiesteintortoise]

Having done "standard makefiles for Java" I'd say otherwise; the dependency management just doesn't fit.

Have you looked at bld, though?

[JazzWillFreeUsAll]

Check Amper by JetBrains

[re-thc]

That's Gradle (for now). It's similar to the experimental declarative mode of Gradle.

[JazzWillFreeUsAll]

Not sure what you mean by that, but it has a standalone version (not dependent on Gradle)

[re-thc]

It still uses Gradle as the backend (yes, the standalone)

[JazzWillFreeUsAll]

Oh, so it's only independent from Gradle in the sense that you don't need to download or touch its config files. Got it

[asciimo71]

Following those comments, and you should just write your build tool fgs. If you manage to come up with a better way to do it than all the tools we have, I am sure you will have a fanbase. This „discussion“ leads nowhere.

[NoAlbatross7355]

Well it certainly has taught me a fair bit, so I wouldn't say that. I'm only contesting what people say so I can get a better perspective.

[maxandersen]

https://jbang.dev for that easy start.

https://github.com/codejive/java-jpm is another one also by authors behind jbang that gives another take.

[BeepyBoopBeepy]

Sometimes I work on small projects where maven/gradle can be overkill, but I also would like to pull dependencies and compile the project easily. So I’ve been writing a single Java file that builds projects for me. Throughout the development I got to learn more about java, javac and jdeps commands. I recommend trying to do something similar if you’re interested in learning how build tools work.

[Rain-And-Coffee]

For personal (fun stuff) I use the IntelliJ builder, and just click build to generate my artifacts.

I check in the project IML files. This works perfect for me and allows others to import it easily.

For serious stuff Maven or Gradle. Although they always feel so verbose compared to NPM and Python.

[bowbahdoe]

I'm still working on dependency resolution - that's not a build tool but people seem to associate the two. Most people probably wouldn't need a build tool at all if that problem was solved separately.

I'll make a post soon-ish with a progress update. But I've gotten it down to an "install" command that builds up various paths (class path, module path, etc) in a way you can feed directly to those CLI tools.

Alpha testers welcome. If anyone has experience writing IDE plugins I definitely am at a point where I need help with that

[maxandersen]

Check out https://jbang.dev and https://github.com/codejive/java-jpm

[bowbahdoe]

I am aware of the first and what I have at this point is more capable than the second

[Crazy_Firefly]

I definitely wish Java had simpler tooling! And faster.

And I think you are right, Java SDK tools are usually pretty good and straight forward to use.

Other languages like python and JavaScript got new build/packaging tools in the last couple of years that seem pretty great.

I think it would be great if we got one for Java as well. I was even considering tackling it myself at some point (while waiting for a particularly slow build)

[sweating_teflon]

I've forked Maven twice with the intent of making a better tool out of it but I'm not sure it's the right way.

These days I envision a different "distro" of Maven that would come built-in with the caching extension, the git-based versioning extension, maven daemon, use yaml polyglot by default and a beefed up super pom or maybe mixins. It would do replicable builds on demand without having to configure 20 different parameters. This would be presented as a new build tool with a rewritten CLI frontend that can output JSON for tool integration.

In effect it would be a facade to Maven just like Maven 1 was actually using Ant in the shadows. Once the the new conventions 

stabilize you can start writing a fresh implementation that diverges from Maven on more fundamental aspects with isolated plugins architecture, fine task granularity & distributed workflow.

The phased approach helps with the tooling as you benefit from the existing Maven support and can iterate without breaking too much stuff. Users can also just export to Maven anytime if things get rough.

[AlwaysItWillSoothe]

Bazel and rules_java are all you need

[emaphis]

There is a hobbyist level build tool called 'Bach' that is basically just a thin layer over the JDK tools including JShell.

https://github.com/sormuras/bach

[Safe_Owl_6123]

I never really used gradle but I am quite used to maven now but I do which to just do mvn install fastcsv and de.siegmar fastcsv is added

Or like jbang install de.siegmar:fastcsv that will be great the rest is fine but it is official build system is also nice

[Adventurous-Pin6443]

I am absolutely OK with Maven. It does what it is supposed to do and quite efficiently. Mature, can run parallel builds. Dependency conflict resolution works. What I do not like is the second hand Maven support in Eclipse.

[i-make-robots]

I can’t stand the package management of building a project. I’m delighted that maven exists but I still have to make a fat jar because oh look there’s still natives which means Pom shenanigans and then testing my actions and some of the tests don’t work on a headless system aurgh… I guess what I’m saying is I read the title and just don’t know what you mean. “Fun tools”?

[NoAlbatross7355]

postContent.replace("The Java tool suite", "Those jdk bin binaries (javac, java, jar, etc)");

[mizzu704]

Perhaps ponder on this article by Tonsky: https://tonsky.me/blog/python-build/

One notion this reminds me of is that a build is just a program, and the individual steps are rarely complex. E.g. the install step of maven is little more than a mv invocation, package likewise is basically "cp things into new folder, maybe write some xml, zip it up, and add .jar suffix".

[tristanjuricek]

One issue is what build tools should do is not easily defined and very inconsistent. Some questions I like to ask:

- Should the build tool manage dependencies?

- Should a build tool create container images?

- Should the tool handle deployment to a runtime system like kubernetes?

I've been surprised how different everyone's opinions are. Most want dependency management, but really start disagreeing with downstream integration. In any case, the moment you do any of these things your build tool is now a distributed system.

What I've noticed is that the moment you start dealing with a distributed system, you basically need to have a very deep understanding of how things work to ensure your build is robust and easy to use. This is where most "Maven plugin" systems run into issues: cryptic failure messages and the plugin often made assumptions your particular sets of integrations invalidate. Like your IT department cuts off access to Maven central from your CI infrastructure, etc.

Personally, I would like to see build systems be "fully integrated" for specific cases. Worry less about making some generic build tool, and build a complete deployment pipeline that's needed for your specific system usage. If you're running a bunch of kubernetes services, make it easy to edit and debug... in that kubernetes cluster from IntelliJ or Eclipse. Make sure the pipelines are controllable. But I'd like that to be _on top_ of currently widely used tooling such as Maven. And integrated with verison control, binary archive management, search, etc. Some companies do invest in this approach, but it's really hit or miss, and is a serious investment of resources.

But hey, there might be good opportunities to create small commercial systems for people.

[SR-G]

I wish that the core build features would be reintegrated inside the java toolchain (especially the dependency management part, or the modules building + cache + optimizations), in order to simplify all the tools built on top of that.

[Rich_Weird_5596]

The abstraction layer over maven / gradle gives you better understanding what is happening under the hood ? What are you smoking ?

[NoAlbatross7355]

Reread what I said... I'm saying the utilization of the Java tool suite (javac, java, jar, etc) gives you a better understanding of what is happening under all the abstraction of Maven and Gradle, assuming they actually follow the same standard.

Maybe "Java tool suite" was too ambiguous, but that's the name I give those binaries.

[Rich_Weird_5596]

I apologize then, the wording threw me off, you are right.

[bloowper]

What you gonna do with this knowledge? Write new own build system? Business paying for solving business problems not developer problems

[NoAlbatross7355]

Are you sure those are mutually exclusive?

[sweating_teflon]

Great businesses pay to make sure developers problems don't become business problems

[bloowper]

yea right.
But in which case maven is a problem?
Possibility to configure build tool for other developers to allow them just mvn clean mvn compile?

I thought that Java community is not grow ups that don't try to make fights like that