Learning build system - is Gradle a good place to start?

[Quazi Irfan]

I am learning java and I am trying to find a suitable open source project to contribute. But most of the projects I find are using some sort of build system to compile their java code. The problem is I don't know much about any build system. The only thing I know that a build system is that it automates the build process for a project. Executing many lines of terminal commands from a single file, which otherwise would have been a tedious process for the developers.

So far I've found Ant and Maven are the most widely used build tools for Java. But the one I need to learn to contribute to jMonkeyEngine is Gradle.

Since I have no prior experience with any build system, would it be okey if I start with Gradle, without learning Ant / Maven? Knowing Ant / Maven seems like a must for any java developers, since they are widely and they come with almost every IDE(Netbeans, eclipse) by default.

And for me, I am more inclined towards learning from the basic.

[Tim Cooke]

All those build tools essentially do the same job, just with different methods of configuration. Learning Gradle would be a good place to start as it is the newest of the three you mention (Ant, Maven, and Gradle). I would strongly recommend you do take the effort to learn about the problem you are solving with a build tool, as opposed to just learning the syntax for building a project without really understanding what's going on. That way you will also gain an understanding of what Maven and Ant do, so if you come across any of those tools out in the wild it'll just be a case of learning it's syntax language.

In my experience, Ant is not used that much any more. I've been programming professionally for nearly a decade now and even I seemed to have missed the Ant popularity wave. The systems I have worked on, and still do, predominantly use Maven as the build tool. However, for any personal Java projects and such, I would favour Gradle. That's mostly because it's easy to mix in Gradle support to enable me to use the Spock testing framework.

[Quazi Irfan]

Thanks Tim. That really cleared the water.

But what if I face old codes that has Ant build files, would I be able to use Gradle with it? For example, automatically converting the Ant build to Gradle build? Or what should I do in these cases in general?

[Tim Cooke]

I know that Gradle has a feature to convert a Maven built system into a Gradle built system, and it does work, although my trust level in that would decrease quickly the further away from a 'standard' configuration my Maven configuration was. As for converting from Ant... I have no idea.

If the project is completely yours to mess around with then you can have a go at converting to Gradle, if only for the practice and knowledge gained through experimentation. However, if it's a shared project owned by someone else then you might just have to 'go with the flow' and use Ant or Maven or whatever. If you do want to work on these systems, then you have no choice but to learn enough Ant or Maven to get by. For example, I have a project that I contribute to from time to time that is built with Ant. I have no intention of learning all the ins and outs of the Ant build tool, but I've learnt enough of the commands to build the project and perform the tasks that I require, which I'm sure is a tiny tiny part of its overall capabilities.

[Quazi Irfan]

Thanks again Tim.

Can you tell me a little more about there others terms and tools(at a very basic level) I need to know if I want to venture into the wild.

For example, I don't know what's Continuous integration is and what Build Script Automation is - does it mean some tool will generate the build file out of thin air for my project?

[Knute Snortum]

Quazi Irfan wrote:I don't know what's Continuous integration is...

Continuous Integration (CI) is often used in situations where many developers are all working on the same code at the same time. It basically is a server that pulls the latest "commit" of the code (more on this later) and builds it, reporting any errors. The point is that you should always have a "buildable" project, even if it's not complete. You, the developer, usually don't have to do anything to run CI; it is usually setup by sysadmins.

Version Control Software like git is use to commit versions (snapshots) of your code so that a) your committed code is always buildable, and b) you can go back to a previous version. There is a lot more to it but that's the basic idea. The CI server usually pulls the latest commit of all the developers' code and builds it.

and what Build Script Automation is - does it mean some tool will generate the build file out of thin air for my project?

ant, Maven, and Gradle all are considered build script automation (although Maven is really driven from a config file, not a script). If it's our project, you have to create the script/config file and then it will build the entire project for you. If you are coming into an existing project, they probably have already created the build script and you just have to know how to run it.

Googling Continuous Integration, git, ant, Maven, and Gradle will give you a wealth of knowledge about these concepts.

[Quazi Irfan]

I've Googled about them a lot. But the problem with this picture is, the components themselves are so huge that the connection in between them seems less of a focus everywhere.

I wish there was "A Complete look of Software Development Life Cycle for Beginners" book that would give me a dummy project and the book would skim over all the tools that is being used a general production pipeline.

[Knute Snortum]

I gave you a bit of the connection between CI and git. Gradle can call ant and can use Maven repositories, but basically they stand on their own. CI will be setup for you, but you will need to know the basics of git. Between Maven and Gradle, I would pick Maven but an argument can be made that Gradle is more up and coming.

[Quazi Irfan]

I am learning Git alongside Java, and I am going to pick Gradle. Let's hope it will be a fun ride.

And Thanks for clearing things up.

[Tim Cooke]

For a beginner starting out and wanting to know what it means to be a 'professional'* programmer, I would highly recommend "The Pragmatic Programmer" by Andrew Hunt and David Thomas. It covers a lot of these topics from the point of why you would want to do them, rather than talking about any particular tool. It's a must for any budding programmer.

(* Not necessarily professional as in paid, but professional as in not amateurish, unstructured, or hacky)