BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News An Alternative Build System: Gradle 1.0 Released

An Alternative Build System: Gradle 1.0 Released

This item in japanese

Bookmarks

Gradleware has recently released Gradle 1.0, a build system targeted at Java, Scala and Groovy. Gradle attempts to consolidate all the good ideas from Make, Ant, Ivy, Maven, Rake, Gant, Scons, SBT, Leinengen, and Buildr and it is already used by high profile projects such as Spring and Hibernate. The capabilities it offers are similar to the popular solutions of Maven and Ant/Ivy already used by Java developers.

Some interesting features of Gradle are:

  • Build scripts are written in Groovy (instead of XML)
  • Support for builds in Java, Scala and Groovy itself.
  • Dependency management compatible with Maven repositories
  • Ant tasks are first class citizens
  • Build in support for static analysis tools (software quality)
  • GUI integration for all popular IDEs
  • The Gradle daemon for faster builds is no longer experimental
  • Programming API for embedding Gradle itself into other applications
  • Experimental C++ support

Both Ant and Maven use XML for their build configuration format. While XML is human readable and has great tool support, it cannot always represent control logic in a convenient way. Gradle overcomes this issue by adopting a full programming language (Groovy) as the build format. This brings the power of a programming language in the definition of the build. Flow conditionals, data variables and all other programming constructs can easily be incorporated into the build process.

An an example Gradle Tasks (think Ant targets) are programming constructs on their own. Here is a Gradle build file that shows this concept:

// Use the default greeting
task hello(type: GreetingTask)

// Customize the greeting
task greeting(type: GreetingTask) {
    greeting = 'greetings from GreetingTask'
}

class GreetingTask extends DefaultTask {
    def String greeting = 'hello from GreetingTask'

    @TaskAction
    def greet() {
        println greeting
    }
}

This will print:

$gradle -q hello greeting
hello from GreetingTask
greetings from GreetingTask

At first sight this feature makes Gradle a very powerful build tool with a lot of flexibility (similar to Ant). Gradle however attempts to find a sweet spot between the power of Ant and the rigidness of Maven. For the supported languages, Gradle includes respective plugins with predefined tasks for the most common operations. Activating the Java plugin in a build file will also define tasks such as clean, compile, javadoc, build, test, check etc.

Dependencies in Gradle are handled in a similar way to Maven. Gradle can use Maven repositories and before reaching version 1.0 Ivy was used for dependency management (which is itself compatible with Maven). For the 1.0 version Gradle implements its own mechanisms for dependency management. Here is an example which shows the similarities with Maven:

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

Gradle is also compatible with existing Ant builds. Not only it can take advantage of existing Ant tasks, but it can also import a build.xml file. Gradle also offers plugins for integrating quality tools in the build process such as FindBugs, PMD, Checkstyle, JDepend, CodeNarc and even Sonar.

For performance reasons Gradle comes with a daemon that can accept build scripts while active. This improves the speed of the build since the overhead of starting (and stopping) Gradle disappears after the initial run. This technique is useful in cases where a large number of builds is executed one after the other, such as during unit testing.

Finally Gradle comes with a special wrapper that allows integrating it into the source code of project. This makes the build self contained since anyone can work with the project without an existing Gradle installation. This is actually one of the weaknesses of Maven, since a Maven project is built on environments where Maven is already installed.

For more information on Gradle see the documentation, release notes and the roadmap. If you find Maven too restrictive, Gradle may be a good alternative solution to your build system.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • the worst parts of ant, with an additional markup/syntax

    by Jason Dwyer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    seriously, if you're doing ant, do ant.

    if you think you need a completely 'do what i want when i want' build, you're probably already doing it with ant.

    if you can accept that just about all build and composition problem has been solved already with maven, just use maven.

    why bother with something that attempts to bridge the worst aspect of ant ( go near any build.xml in a long-lived complex project and you'll soon want to scratch your eyes out following what custom build path they've come up with. now imagine its in groovy, and you'll have the same net result ) with just a little bit of what maven will give you as a minimum ( dependency management ), but still require the maven repo infrastructure anyway?

    then of course you might still have bitter memories of a past life/project which forked an early version of gradle and was forever stuck with it which leaves you still cursing its name 4 years later....

  • Re: the worst parts of ant, with an additional markup/syntax

    by Anton Arhipov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    With Gradle, ant tasks become incremental

  • Re: the worst parts of ant, with an additional markup/syntax

    by Daniel G.,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    seriously, if you're doing ant, do ant

    I actually see it the other way around, i.e. Gradle build files are like a more concise, readable version of Maven POMs: they're declarative, and they borrow and build on Maven's convention over configuration and dependency management ideas.

    However, the Gradle declarative syntax is just a Groovy DSL, and if you need to establish your own custom build convention or "swim against the current" in some way, it's extremely easy to break out of the declarative "box" and write 10 or 20 lines of procedural code in order to change the one thing that you want to customize.

    These are the sorts of extensions that are extremely hard in Maven. Don't want to do one certain thing "the Maven way"? Did the Maven plugin author forget to allow users to configure a certain aspect of the plugin behavior? Time to fork the plugin.

    So I guess what I'm saying is that I see Gradle more as a Maven++ than an Ant++.

    then of course you might still have bitter memories of a past life/project which forked an early version of gradle and was forever stuck with it which leaves you still cursing its name 4 years later....

    I'll be going through this sometime in the next couple of months... wish me luck :-)

  • Re: the worst parts of ant, with an additional markup/syntax

    by Conor MacMahon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    For me, gradle has the "convention over configuration" elegance of maven, plus the "edge-case scripting" of ant. Where gradle has the benefit over both tools, is that it is a full programmable DSL, as mentioned by Daniel and the marketing release above.
    While it will take a bit of time for tool support, anyone with a green-field (JVM) software development project should evaluate gradle for the benefits I have just mentioned.

    Being a veteran of some pretty bad ant and maven builds (like others it would seem ;-) ), I welcome the opportunity gradle gives me to improve the builds of existing systems, plus establish a good foundation build for new systems.

    Regards,
    Conor

    p.s. Forgot to mention, love the wrapper addition to gradle, gradle.org/docs/current/userguide/gradle_wrappe... very clever. For anyone who has had to install the build tool on an external system, you would appreciate this simple but effective feature.

  • Re: the worst parts of ant, with an additional markup/syntax

    by Howard Lewis Ship,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Mostly, what he said

    I've used Ant from early days (circa 2002 or 03), eventually moved to Maven, deeply regretted it by about 06, finally switched over everything I do to Gradle in the last year. I have faster builds, repeatable builds, maintainable builds, and it's very easy to customize or add a little bit of extra logic to my builds.

    Using Gradle gives me a little taste of what Tapestry users feel: you can make it do just about anything you want, in a very small amount of elegant code, but it can take you a while to hunt down exactly what that code is and where it goes. It's usually pretty obvious in retrospect.

  • SBT - Maven-compatible Gradle alternative

    by Michael Swierczek,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There's also Simple Build Tool (SBT), which is partly or maybe completely compatible with Maven. I don't know Maven well enough to compare and contrast them, I skipped right from Ant to SBT.



    SBT has decent documentation, which is good because I found it difficult to learn. But to be fair, I first looked at Maven before its documentation was mature, and back then it was even worse.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT