Welcome your new overlord: Gradle

I’ve been sick the last few days, and figured i’d learn Gradle. I created a Gradle based libgdx template, which you can start using now. It will eventually replace our current Setup-UI to make my life more enjoyable. IT will also allow you to build and run your libgdx projects on the CLI, Eclipse, IntelliJ and even Netbeans. And on top of that, you’ll not have to juggle any JARs or native libraries anymore, everthing is taken care off for you. You can update to different version of gdx, and easily include extensions or other 3rd party libraries. So, what is this magical Gradle?

Gradle is a build and dependency management system, using Groovy and some domain specific language sugar. A build system is responsible for compiling your application and packaging it up. A dependency management system allows you to define which 3rd party libraries you want to use, and the system will automatically pull those libraries in for you. Provided the libraries are available in some sort of repository. The most established type of repository in Java land are Maven repositories, with Maven Central being the global central hub to which almost all things get published to.

Here’s what defining such dependencies looks like in Gradle for a libgdx project that also uses the FreeType and Bullet extensions (no GWT and iOS yet):

The core project references the gdx core API, the FreeType extension and the Bullet extension. The desktop project additionally references the gdx LWJGL backend, and the native libraries for gdx core, FreeType and Bullet in their desktop incarnations. The desktop project also depends on the core project, so it will pull in all the code from the core project, as well as any of the core project’s dependencies!

The Android is a little special due to how things work in Android land. Sadly, we have to reference the FreeType and Bullet extension again even though we also depend on the core project, which should pull in the core project’s dependencies. It’s a long story, and i’m a bit fed up with the mess that is Android’s build system (and no, the new Gradle Android build system isn’t awesome either…). Anyways, that’s how its done in Android land.

You’ll also notices those dependencies ending in e.g. natives-armeabi or natives-debug. These just contain native code in form of shared libraries, e.g. your beloved libgdx.so and consorts.

Adding a new dependency is as simple as finding it on Maven Central, then adding it to that Gradle build file. Once to the core project’s dependency, and once again to the Android project’s dependencies, the desktop project gets things from the core project as it should be.

Say you want to add Kryo by Nate. First you go to Maven Central and search for Kryo, which will bring up the following:

Just click on the first entries latest Version (2.21). On the next site you’ll see the group id (com.esotericsoftware.kryo), the “artifact id” (kryo) and the version (2.21). To add this as a dependency to your Gradle-based libgdx project, just add the following to the dependency sections of the core and android projects

That’s it. Now you can have Gradle regenerate your Eclipse/Idea projects, et voila, you can now use Kryo! Best of all, you have no JAR files in your project directory, for which SVN/Git/Hg will thank you.

You can also change the version of dependencies in the Gradle build file, and it will automatically get the correct libraries for you. No manual copying of things, not chance of messing things up!

You can find the Gradle template over on Github, with full instructions. Go try it out! I’ll add GWT and RoboVM support in the following days. Please report any issues. Eventually i’ll package this up and add a tiny GUI for initial project creation, just like the old setup UI. However, any updates of dependencies and so on will be done by you in the Gradle build file just as illustrated above. This will make that setup GUI extremely simple. More time will be spent on the Gradle build files. E.g. it’s already possible to create ZIP distributions for desktop projects and APKs for Android projects with the current Gradle system. I’ll likely extend that to allow you to create EXEs and App Bundles for Mac OS X and maybe even DEB files for Debian/Ubuntu.

One note: IDE integration of Gradle is still a weak point. IntelliJ Idea doesn’t cope well with multi-module projects. The Eclipse Gradle plugin by SpringSource is OKish, and you can actually use the current system with it. But i sense there will be issues cropping up when used for more complex things.

Also, the Android project uses the new Android Gradle based build on the command line, but uses the Ant based build in Eclipse/IntelliJ Idea. Until the Eclipse ADT plugin understands Gradle that won’t change. Oh, and the Android Studio/IntellJ Idea plugin doesn’t work properly either. It’s all a bit of a hack at the moment, but here’s hoping for a bright and clean future. If you want to give your eyes cancer, check out the Android project’s Gradle build file responsible for making it work with the CLI, Eclipse and Android, and fix the non-handling of native libraries with the new Android Gradle build system. Luckily you’ll not have to touch that file, unless you want to add flavors to your Android project.

19 thoughts on “Welcome your new overlord: Gradle

  1. But Iam hardcore. I wanna add every single dependency by hand. Thats the real joy of programming 😛

  2. That’s great! I feel late to the party, I just discovered GDX recently. It’s such a fantastic library, you guys are doing great work.

  3. ” and even Netbeans”

    I’d love to give that a try.

    Any thoughts on when NetBeans support might be available?

  4. You are so awesome ! Each of your posts makes life so beautiful, thanks for the great work!
    I wish we could make a “Gdx Foundation”

  5. Sounds great. I’ve just managed to run my game (Space Bubble Shooter) on iOS today (yay!) after finding out the main problem was having old jars in one of my libraries (and I was so careful while copying them!). Such tool would solve all such issues I suppose. 🙂

  6. I ran into a nasty floating-point issue the other day when I switched over to Gradle, but it wasn’t really Gradle’s fault. Due to differences in the way the code gets compiled between Eclipse and other build systems, I seem to have exposed some sort of a rare optimization bug that only made itself known on certain devices with certain versions of Android installed (see https://code.google.com/p/android/issues/detail?id=58698 if you’re curious). The joys of hardware fragmentation. 😉

    The benefits of a Gradle build is I no longer have to click a bunch of times to create several builds; one command at the command line and they all go.

  7. Oh my god. Thank you thank you thank you. 🙂

    I was just cracking my knuckles about to get down to gradle-izing my own project so I can use TravisCI. I’m sure it would have been painful.

  8. What is the plan about iOS?
    Let’s assume that my project will be gradle based, is there any way to build the package for iOS? like i.e. copy xyz.jar build with gradle to the “old/current” layout?

  9. This is SWEET! I can’t wait until you roll in IOS/RoboVM builds (any ETA?), and how easy/difficult would it be to get Gradle to compile Scala-based LibGDX projects? Thanks.

  10. For IDEA/Eclipse, have you tried generating the IDE project files and then opening/importing those in to your IDE?

    ./gradlew idea
    ./gradlew eclipse

    In IDEA File->Open and select the *.ipr file.
    In Eclipse File->Import…->General->Existing Projects in to Workspace… and select the root folder and import the subprojects.

Leave a Reply

Your email address will not be published.