1 Reply Latest reply: Jul 27, 2010 4:47 PM by Hans Dockter RSS

    Sample Gradle Build

    Paul Gier Master

      I created a sample gradle build and it's available in my git tree (http://github.com/pgier/jboss-as/tree/gradle).

      If you want to try it out, just pull from my tree into a branch called "gradle"

       

      git remote add git remote add pgier git://github.com/pgier/jboss-as.git
      git branch pgier/gradle
      git checkout pgier/gradle
      git pull pgier gradle
      

       

      Then download and install gradle 0.9 if you don't already have it (http://www.gradle.org/).  And run the build

       

      gradle clean build dist
      

       

      I'm mainly interested in Gradle because it could solve our issues of

      1. a single place to define the version for a multi-module project
      2. deploying poms with resolved snapshots
      3. more flexibility for the distribution build (right now we're using Ant via the antrun plugin)
      4. easier management of dependencies across modules

       

      The build script is not quite complete, but the basic stuff is there, and here are some observations.

       

      Advantages of Gradle

      • The build scripts are smaller, a big part of this is the fact that gradle uses groovy instead of xml, but it is also quite a bit easier to reuse bits of code throughout the build
      • The build.gradle script in the root directory can handle both the module agreggation and the distribution build in the "build" directory, instead of having two poms for this in Maven
      • Gradle has some interesting optimizations, for example it won't re-run the unit tests if the code has not changed
      • I haven't set the pom generation up yet, but Gradle includes some features to generate POMs.  This means that we could generate poms that include resolved snapshot dependencies.  We also would not need to deploy any parent/aggregator pom to the repository

       

      Advantages of Maven

      • We have a lot of Maven knowledge already, and Gradle has a significant  learning curve (this might be easier for people familiar with groovy)
        • This would be especially important for our community members trying to checkout and build
      • Maven forces consistency among projects, and it's easy to see how a Gradle build could become complex to the point of being difficult to maintain.
      • I haven't looked into the reporting features of Gradle yet, but it might not be as easy to use as Maven

       

      Other Notes

      The speed of the builds seem to be similar.  For me this was about 15s for a clean build and 8s for an incremental build.

      Overall Gradle is very interesting because there are lots of possiblities that open up when your build scripts are actual code instead of just a set of plugins, but it's easy to see that the complexity of a gradle build could get out of control.

      I prefer Maven's logging which is more verbose than gradle.  Maven prints out the log level and prints summary information at the end of the build.  Gradle's logging seems to be based on the steps of the build and not so much grouped by module.

        • 1. Re: Sample Gradle Build
          Hans Dockter Newbie

          Hi Paul,

           

          thanks for setting up this Gradle build. A number of comments:

           

          Build Speed:

          We usually consider the average build time and the time for full build. Regarding the average build time Gradle, depending on the build type, is way ahead of Maven with the incremental build and the parallel testing feature (although Maven does provide some parallel testing support via JUnit). We have a new experimental branch that uses a preconfigured JVM which gave us a dramatic performance improvement. So now even for a full build we are clearly ahead of Maven 2 and 3-beta-1. See: http://gradle.markmail.org/thread/xbqna6lowvsmm4ve

           

          Logging:

          We really like our minimalistic logging . In fact we think it should be even more minimalistic and we are working on that. Our default logging is focused for a user of a build, not for a buildmaster. We think that verbose output easily hides relevant warnings and strange behavior. You can always get more information by running gradle with -i and -d. We have started in 0.9 to make the console output more dynamic (e.g. test counter, currently running task). We will continue on that route. With all the history we have we can provide for example a progress indicator based on the last execution time, etc .... And we want to add colors!

           

          Complexity:

          We think as with every complex domain, complexity can get out of hand. Be it in the build or in the production code. Our Java plugin provides a similar skeleton then the Maven lifecycles. For projects where this is suitable. I can't see why people would not use that. We need to do a better job in showing what is relevant for a normal user to execute and what not. We have just added some (configurable) grouping when doing gradle -t. Besides that I'm convinced that Gradle enables _more_ maintainability then Maven for complex build. But the build master has to do a good job as well, there is no way around that. I have written a little bit about this for a German magazine. Unfortunately only the first part of this is translated to English yet: http://jaxenter.com/maven-vs-gradle-vs-ant-27760.html

           

          Reporting:

          We don't provide the same out-of-the-box experience as Maven for some important reports (e.g findbug). But this is no big deal and all important reports will be added as part of 1.0. Until then it is easy to use the corresponding Ant tasks to get those reports. Sonar 2.2 only works for Maven but they are working on becoming tool agnostic in their next release. We are very much looking forward to that.

           

          Cheers,

           

          - Hans
          --
          Hans Dockter
          Founder, Gradle
          CEO, Gradle Inc. - Gradle Training, Support, Consulting