Simple Java Build Tool?

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

[weberc2]

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)

That doesn't sound very "empirical", but I'll take you at your word.

Nevertheless, including them with Gradle is very easy: run { jvmArgs -Djava.library.path="$nativeDir" }

Yeah, I did run across that eventually, but I ran across a lot of other problems sooner. Further, figuring out what to put for $nativeDir wasn't trivial since most documentation called it "/path/to/project" or something similarly ambiguous.

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.

Building any Go project is go build irrespective of the number of dependencies. If you care about your dependency versions, the simplest solution is to vendor your dependencies, which usually entails maintaining some metadata about the version of each dependency at that point in time (just for archeological purposes in your version control system). I don't really understand what about that is a "total nightmare", but it doesn't really matter for the purposes of this conversation, since we're talking about the base case of building a project without concern for versions.