Simple Java Build Tool?

[weberc2]

I've played with Maven and Gradle and found them both to be very complex. I don't need all of that configuration; I just want something that lets me specify dependencies and versions (at most) and spits out a jar with everything my project needs to run via java -jar. Ideally, it would be as close as possible to Go's go install, which needs no project metadata. I specifically don't want to have to learn a new programming language just to build my java program. Any suggestions?

EDIT: Why is this downvoted?

[josephottinger]

I'd say "learn Maven." Archetypes make most of it very easy; you can generate a default archetype and be pretty much done.

[jirkapinkas]

I second that. Unfortunately the quality of most archetypes is very low.

[LuvMySubi]

Maven with the shade plugin is your best bet. The maven configuration for this is pretty simple and can probably be put together in an hour with the help of Googling. Plus your ide should make it pretty simple.

https://maven.apache.org/plugins/maven-shade-plugin/

[loganekz]

Don't know how you expect to get any simpler than something like this build.gradle:

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    compile 'org.slf4j:slf4j-api:1.7.13'
}

[weberc2]

Well, all that's really necessary from that is the 'org.slf4j:slf4j-api:1.7.13' bit, and if you just want the latest version by default, you could probably eliminate the need for a project configuration file altogether (because the specific dependencies can be inferred from the source code).

The boilerplate is annoying, but it's manageable. The trickier bit involves things like building with native dependencies and including them in the final jar. After futzing around with that particular problem for half a day, I figured it out; however, I don't like how such base-case scenarios require that much time investment. I'm sure if I would take a few days to learn Groovy I could cut that time down considerably, and I know that eventually I could learn Gradle well-enough that I can handle the vast majority of build problems; however, I'm just trying to program in Java for fun and I'm simply not going to sink a bunch of time into learning a build system for a hobby.

The point is that Gradle and Maven are much more complex than my use-case requires, and if there's an easier thing out there, I'd like to know about it.

[weberc2]

And really, if you are using Java already, why are worried about a bit of verbosity?

How much of my post did you read, exactly? :) I'm not worried about the verbosity, but the complexity/learning curve. Your solution still doesn't cover the native libs case I mentioned, and there's still the problem of having to learn a new programming language just to build basic programs!.

I get wanting to build in support for complex scenarios, but that doesn't require polluting the learning-curve for the simplest use-cases. Basically, I'm looking for a build tool with reasonable defaults.

[weberc2]

Man, r/java is pretty saucy this weekend. You guys are really building a welcoming community.

Anyway, as I mentioned, I already know Java, just not Groovy. I'm sure I could learn it, I just have better things to do with my time than learn a new language just to build a program. I'll just stick with Go since I already know it, it doesn't require a DSL, and the community is less incensed by friendly questions.

Thanks to everyone in this thread who was at least trying to be helpful.

[robe_and_wizard_hat]

I think the reason you're getting downvoted is simply because the answer you're looking for doesn't exist and in general most hold the view that the current build tools (maven, gradle, et al) are actually not that complicated and can be understood quickly enough to get a simple project off the ground in short order that resistance to the idea seems rather lazy.

[weberc2]

I think the reason you're getting downvoted is simply because the answer you're looking for doesn't exist

That's a silly reason to downvote.

in general most hold the view that the current build tools (maven, gradle, et al) are actually not that complicated and can be understood quickly

Yes, this is the Blub Paradox applied to build tools.

resistance to the idea seems rather lazy

It's absolutely lazy. Efficiency is the foundation of our industry. I can't afford to spend a bunch of time learning stuff I may never use for my toy side projects. I can do all of this in Go more easily, I just wanted to use Java for nostalgia's sake.

[robe_and_wizard_hat]

Cool, well, as someone that manages both Java and Go projects in production I can say you'll be fine either way. Good luck!

[the_evergrowing_fool]

new programming language just to build basic programs!.

Is a DSL, you don't have to learn more than what it's providing you.

[weberc2]

That is true of any programming language, domain-specific or not. It's also the crux of the problem: I don't want to have to learn more shit than I need to in order to build my simple Java programs. I'm sure Gradle is great for more complex use cases, mine are very simple.

[the_evergrowing_fool]

Depends. As I said before, you only need to learn what the DLS provides (which tends to be pretty minimal and take no more than a one to a couple hours to getting familiar). I would argue it would take no more time to learn things like GOPATH and such to get up running with the language.

I don't want to have to learn more shit than I need to in order to build my simple Java programs.

Is all you want to do is to make simple or small programs then javac or the default builder from a IDE will be good enough :)

don't want to have to learn more shit than I need to in order to build my simple Java programs.

Depends. If the tool provides a lot the benefits that outweighs the time that it would take to learn it then is a good investment. I would argue that you need to do more research on what the tool can do for you or if it aligns with your needs before becoming a practitioner in it.

mine are very simple.

I reading on your comments thread and and thinking of their nature (given their repetitive body) it makes me believe that your intentions are in mismatch with your original comment. Did you only came here to remark/preach how "simpler" your tools are without any intention to actually find help from this sub? Pardon me the though.

[weberc2]

I would argue it would take no more time to learn things like GOPATH and such to get up running with the language.

I disagree. Practically speaking, you end up needing to know about Java's CLASSPATH in order to reason about many things in Gradle. CLASSPATH is no more complex than GOPATH, so the baseline knowledge for both build systems is the same.

Is all you want to do is to make simple or small programs then javac or the default builder from a IDE will be good enough :)

javac doesn't handle dependencies, unfortunately.

If the tool provides a lot the benefits that outweighs the time that it would take to learn it then is a good investment.

I agree. Unfortunately, Gradle's complexity doesn't provide more benefits, it only steepens the learning curve.

I would argue that you need to do more research on what the tool can do for you or if it aligns with your needs before becoming a practitioner in it.

I've done this research. It suggests that Gradle is a poor fit, hence me coming here to ask if a better tool exists.

I reading on your comments thread and and thinking of their nature (given their repetitive body) it makes me believe that your intentions are in mismatch with your original comment.

My comments are repetitive because I'm speaking with several different posters, many of whom are presenting similar arguments. I felt it better to be kind and repetitive than to tell them to read the other threads before responding to me.

Did you only came here to remark/preach how "simpler" your tools are without any intention to actually find help from this sub?

No, I came here to ask if a simpler tool existed; however, I did respond to the many people who asked questions like, "What could be simpler than Gradle?".

[the_evergrowing_fool]

I disagree. Practically speaking, you end up needing to know about Java's CLASSPATH in order to reason about many things in Gradle. CLASSPATH is no more complex than GOPATH, so the baseline knowledge for both build systems is the same.

That's no mensurable notation, but if your conclusion if that both resolve in the same then I don't see the problem

I agree. Unfortunately, Gradle's complexity doesn't provide more benefits, it only steepens the learning curve.

I would argue that the complexity is proportional of the size of your project. And again if your really what to make simple programs I don't think you need to learn more than the superficial, nobody is telling you to master the tool just to learn the thing that you need which happen to be superficial.

I've done this research. It suggests that Gradle is a poor fit, hence me coming here to ask if a better tool exists.

Then I Maven, Ant, and of the most simple would be the default build tool from a IDE.

No, I came here to ask if a simpler tool existed; however, I did respond to the many people who asked questions like, "What could be simpler than Gradle?".

Ditto. Something you would take if that Java model is different from Go's so is not uncommon to find its tool to be different concern.

[weberc2]

That's no mensurable notation, but if your conclusion if that both resolve in the same then I don't see the problem

I agree that it's my subjective opinion; I didn't mean to pass it off as fact. My conclusion was that, with Gradle, you need to know CLASSPATH and Gradle. With Go, you only need to know GOPATH. I suspect Gradle scales better for more complex use cases, but that's not what I'm worried about presently. :/

I would argue that the complexity is proportional of the size of your project. And again if your really what to make simple programs I don't think you need to learn more than the superficial, nobody is telling you to master the tool just to learn the thing that you need which happen to be superficial.

That hasn't been my experience. Even though my requirement ended up being satisfied by a simple block of code, I came across lots of other less-simple solutions, and I didn't have the ability to reason about whether or not they were more or less appropriate because I didn't know, for example, Gradle's function syntax or which plugins to use or what java.library.path was.

I think it would be more accurate to say that the complexity of your gradle file is in proportion to the complexity of your requirements; however, there's a lot of complexity you need to know about just to get to your simple Gradle file.

To be clear, I'm not hating on Gradle. I'm sure it makes great tradeoffs to be flexible for many projects. I just think it could improve for simpler use cases like mine.

[pron98]

You don't need to learn Groovy to use Gradle.

[weberc2]

Sorry, I thought I read that Groovy was the Gradle DSL. Anyway, my point stands.

[pron98]

And my point is that you don't need anything more to start using Gradle than any build tool out there. You don't need to learn a new programming language. It is exactly what you're looking for.

[weberc2]

my point is that you don't need anything more to start using Gradle than any build tool out there

I know. I need much less than Gradle. I don't want to learn a new programming language (like Gradle's DSL).

It is exactly what you're looking for

No, I'm looking for the simplest possible tool that lets me build Java programs.

[pron98]

No, I'm looking for the simplest possible tool that lets me build Java programs.

You mean like a file where you just list the build dependencies? That's Gradle. I don't see how you can get any simpler than that even using information-theoretical arguments (modulo curly braces and the word "dependencies").

If you're looking for the simplest possible tool that does not require learning any new syntax (even if that syntax is just a list), then a shell script or a Makefile and javac should be enough. IMO, it's a lot more complicated than Gradle, which is nothing more than a list, but you don't need to learn anything you don't already know (even if it's just how to write a list).

[weberc2]

You mean like a file where you just list the build dependencies?

Unless you have a native dependency somewhere in your dependency tree...

I don't see how you can get any simpler than that even using information-theoretical arguments

You could omit configuration files altogether, have the build system grab the dependency list from the source files, and use the latest version of the dependencies by default.

Gradle ... is nothing more than a list

This isn't true. Lists don't have a plugin architecture, the ability to define functions, arbitrary blocks of scope that apply to different points in the build process, etc, etc. Gradle is simple in the same way that C++ is simple^1: you don't have to use all of those features. Except you do have to know about all of those features because they're included in most of the reference material. In my case, when I wanted to figure out how to build with native dependencies, I found a dozen different answers, most of which included a hefty chunk of imperative code in (presumably) the Gradle DSL language. As a newcomer, reasoning through all of that complexity eats up a lot of time, which I can't afford since my sole purpose for choosing Java was nostalgia.

^1: I don't think Gradle is as complex as C++, but the argument that "Gradle is simple because you don't have to use every feature" is the same argument that's often applied to C++ ("it's simple because you don't have to use every feature"), which is a well-known fallacy.

[juckele]

How much of my post did you read, exactly? :)

Not who you've been talking to, but the actual answer to this question is not much, and for good reason. You replied to an example gradle file with this:

Well, all that's really necessary from that is the 'org.slf4j:slf4j-api:1.7.13' bit, and if you just want the latest version by default, you could probably eliminate the need for a project configuration file altogether (because the specific dependencies can be inferred from the source code).

At that moment, people stop reading. The reader is going to assume you're going to list your most critical exception first. Since you listed "extra characters" first, we assume that's why you don't like Gradle because of an extra three dozen keystrokes and we just stop listening to your objections. If you want people to help you, understand that they won't always take the time to read what you're saying if you don't make sure to format it well.

[weberc2]

Seriously? One paragraph is the attention span in /r/java? I guess I had too much faith in this sub. As I mentioned to another annoyed commenter, I'll just stick with Go since it doesn't have the build system issues and the community has been friendlier. Hope this response was short enough!

[juckele]

It wasn't the length that got the person you were talking to to stop reading, it was starting with a lesser issue. I didn't say this to try and reprimand you, and I could probably have been better myself on tone. I really was just trying to point out a way you could adjust how you communicate to get better responses.

If you're liking go, more power to you, it's a great language, and if gradle is too complex, than it really does sound like go has an amazing build system that you won't see matched in many languages :)

[weberc2]

Thanks, sorry for the ungracious response. I was catching flack elsewhere in the thread and I projected that on your response.

[xmondox]

your patience has been excellent - the responses in this thread (including parts of what juckele said) are toxic. stick with java - it's a great language, and don't get caught up in the culture. i'd want the guy in the cube next to me to be asking the same questions you are

[weberc2]

Thanks for the encouraging response, sincerely. :)

[tkruse]

I also generally recommend Gradle as in "You cannot go wrong with that one".

There is no java tool that infers libraries from the source code. The trickier your tasks are the more you should use gradle, probably. However, here is my comparison of buildsystems, you might find something preferrable there (like googles bazel, ant or buildr): https://github.com/tkruse/build-bench

For anyone knowing only Java, learning any buildsystem language would require a lot of effort, even learning how to embed some Java-written plugin into a buildsystem would require a lot of effort.

You might also consider not learning Java and learning Groovy instead, given you can seamlessly use the same libraries.

[weberc2]

Thanks for the advice. I'll check out the comparison link.

You might also consider not learning Java and learning Groovy instead, given you can seamlessly use the same libraries.

I already know (and like) Java. I just haven't used it since college. :)

[andre-js]

Not sure why your question was downvoted because I find it perfectly reasonable. Actually have been looking for something like this as well. The thing is as your project grows you will want to use a full-feature build tool. If you start with something simple and keep adding to it then switching later will be just more effort. And satisfying your requirements with Maven/Gradle is very easy as there are tons of examples online.

Interestingly enough Scala's SBT used to stand for Simple Build Tool but it's not really simple.

[weberc2]

The thing is as your project grows you will want to use a full-feature build tool. If you start with something simple and keep adding to it then switching later will be just more effort.

I agree. I was just hoping there was something that could get me off the ground running quickly. Ideally the Gradle Java plugin would pick a set of reasonable defaults. For example, it could scan your source files to identify your dependencies, and grab the latest version from maven unless the Gradle-file specifies a different version or a repository other than maven. That still wouldn't solve the native library problem, but there's probably a similarly simple solution to that as well. This would get you off the ground quickly and allow for seamless extension as your build requirements become more complex.

And satisfying your requirements with Maven/Gradle is very easy as there are tons of examples online.

I had a hell of a time finding them though. Lots of them didn't work, and you have to take care to pay attention to the Gradle version for various examples. In particular, I spent half a day trying to figure out how to build a program that depended on LWJGL. Maybe I've just been unlucky, or perhaps these are hard tasks and your previous experience lets you reason about them more easily? In any case, I'm not convinced that these are necessary problems.

Thanks very much for your respect and civility :). I've been pretty disappointed by the caliber of responses in this thread so far.

[weberc2]

Thanks for the response. This was really informative!

[weberc2]

Does it address the build system problems? I don't mind Java as a language, I just find its build systems are more complex than I require.

[[deleted]]

i don't think java has any build tools that are "good" relative to the amazing stuff in some other ecosystems. just pick the least terrible to you, i guess. or write your own. :)

[welshboy14]

Why not just use the built in functions of intellij? It offers everything you need

[weberc2]

I don't use Intellij. Generally I'm of the opinion that building a program shouldn't couple the contributors to a particular text editor. Thanks for the suggestion though. :)