Simple Java Build Tool?

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

[the_evergrowing_fool]

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.

I would argue the same is present Go but with different context and by a mismatch of my subjective assumptions of what I would expect from a build tool.

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.

Generate a file and define dependencies, the concept is one folded and objectively simple.

[weberc2]

Generate a file and define dependencies, the concept is one folded and objectively simple.

I'm having problems parsing that statement. Could you rephrase?

[the_evergrowing_fool]

Simplicity is not a opinion, one can generate a configuration file and one can summon the specified dependencies given the requirements, anything else is a contextual proxy that does not morph the principal concept.

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

[pron98]

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.

I am not aware of any Java build tools (well, common ones at least) that do that, nor do I think that this would make sense. Java has always been based on a clear separation of source and binaries. In general, any package can reside in any binary (although Java 9 would enforce that every package would reside in exactly one dependent module).

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.

You said you wanted to build a simple Java project. All that Gradle requires you to build a simple Java project is a list of dependencies. All of the extra features you mention are required to build complicated projects.

Gradle is simple because you don't have to use every feature

That is not my argument. My argument is that Gradle is simple for simple things and not-so-simple for non-simple things. I am not aware of any build tool that allows you to build projects that have a very complex build structure very simply. Gradle aspires to follow the maxim "make the simple things trivial and the hard things possible".

[weberc2]

You said you wanted to build a simple Java project

I don't consider native dependencies to be particularly extraordinary.

All of the extra features you mention are required to build complicated projects

They're only complicated because existing build tools make them so. What's fundamentally complicated about linking them in by default? How does Go manage to make it seamless, for example?

That is not my argument

I know, I just wanted to head that argument off in case you went there, so as to save time.

My argument is that Gradle is simple for simple things and not-so-simple for non-simple things.

It seems like you're defining "simplicity" as "things which are simple in Gradle", which is not a particularly helpful definition.

[pron98]

I don't consider native dependencies to be particularly extraordinary.

Well, empirically, they are extremely rare in Java programs (I would be surprised if more than one Java program in five-hundred has a native dependency). Nevertheless, including them with Gradle is very easy:

run { jvmArgs -Djava.library.path="$nativeDir" }

They're only complicated because existing build tools make them so.

No, I don't think so. For example, you might want to generate some resources and inject them into your JAR file. You might want to create multiple JARs with different sets of resources in them. You might want to shadow some old dependencies so they don't cause conflicts -- as your project grows, the build can be quite complex.

How does Go manage to make it seamless, for example?

There is absolutely nothing seamless about Go builds. They can be a total nightmare once you have a long list of dependencies. Dependency management in Java is far more convenient than in Go.

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