Gradle 1.8 is released

The Gradle team is excited to announce the release of Gradle 1.8, now available for download.

The release notes contain detailed information about what’s new and improved in this release.

As always, please share your experiences with Gradle 1.8 via the Gradle Forums.

What’s New in Gradle 1.8?

As always, we’re excited about all of the features and changes in this release. To make it easier to understand this release, we’ve selected three important improvements and highlighted them here:

Look, Gradle 1.8 Can Handle C/C++/Assembler Builds

Earlier in the year we telegraphed that this was coming, and we’ve delivered on the promise. Gradle is quickly becoming a 1st-class build tool for C and C++ builds. Here’s a quick example of how you can configure a build to compile and assemble a program from both C and Assembler source:

sources {
    main {
        c {
            source {
                srcDirs "sourcefiles"
                include "**/*.c"
            }
            exportedHeaders {
                srcDirs "includes"
            }
        }
        asm {
            source {
                srcDirs "sourcefiles", "assemblerfiles"
                include "**/*.s"
            }
        }
    }
}

Many of you support builds that span several languages from Java to C/C++. With our support for native builds you don’t have to work with Make to support C/C++ builds you can build everything in a single, unified build.

Gradleware only started working on this C/C++ support a few months ago, and the speed with which this feature is being implemented is a testament to the strength of the Gradle community. There are still two pieces of native support that need attention: a smarter approach to incremental builds and parallel compilation. Both features are on the roadmap.

Over the course of the next few releases you can expect Gradle to transition from a viable option for native builds to the clear choice for compiling builds that involve C and C++. Its been a long time since a project applied more modern build techniques to native applications, and we’re confident that there are a few things that Gradle will be able to do better than the alternatives. Stay tuned. If you are interested in our C/C++ support, please contact us as we are still defining requirements and planning these features.

Builds Run Faster and Consume Less Memory in Gradle 1.8

Gradleware supports the largest builds in the industry, and some of our clients have builds with thousands of components. Because of this, we’re constantly looking for ways to make Gradle more efficient for builds “at scale”. We’ve made specific changes to 1.8 that reduce the heap consumption for large builds. Prior to Gradle 1.8, Gradle would resolve full dependency information and keep this information in the heap over the course of a very large build. This resulted in two side-effects:

  1. Gradle was consuming more memory than it needed for any given build. When you have a build with a thousand components, you don’t need to store the entire dependency model in memory for every build. Instead you only need a specific portion of that model at any given time. 2. Build performance was affected by garbage collection times. When you have a large heap, garbage collection takes more time.

Large builds were paying a double penalty – unnecessary memory consumption was unnecessarily wasting time. In Gradle 1.8, we fixed it. Dependency information is read in during configuration and it is streamed to disk. For any given build within a large build, Gradle will only store the dependency information it needs in the heap. This translates to minutes of time and Gigabytes of memory saved for the largest builds.

Sick of Waiting for your IDE? Upgrade to Gradle 1.8

Gradle 1.8 has a newly improved Tooling API that has been designed for faster import speed. One of our internal tests involved a project import process that was taking 1:45 for a project import. With some targeted changes to how Gradle’s Tooling API works, we were able to reduce that time to 7 seconds. In other words, we just allowed you to reclaim 1:38 seconds of your life from waiting on your IDE to finish importing a Gradle project. (You’re welcome, BTW, to use that extra time saved to ask your colleagues to start using Gradle.)

IDE integration for build tools is a particular problematic part of the industry. Who among us hasn’t waited weeks of his or her career staring at an IDE as it tries to import something of just freezes for no good reason. At Gradleware we understand how much time is lost on IDEs, and we’re lucky to be working with both JetBrains and Google’s Android team on what we consider to be the most efficient integration API for a build system in the industry.

Component Status Schemes If you use Ivy, you are a familiar with component status schemes. Instead of depending on a version number you can depend on the latest “integration” build, the latest “milestone”, or the latest “release” build. From a Maven build you can really only depend on two implicit status schemes – “snapshot” and “release” – as Maven doesn’t handle status schemes outside of that list.

When we’ve done in Gradle 1.8 is give you the ability to customize status schemes and status in the component metadata rules. This means that you can define a custom status scheme with your own values. For example, imagine that you are working in an environment that produces different levels of builds or different environments. In this case a custom status scheme can be used when defining dependencies.

At the moment, status schemes may only make sense to users who are familiar with Ivy’s approach to status schemes. Going forward, this feature may be developed to work with repositories managers and repositories that can expose status associated with a particular component. There’s a lot of room for changing the way we download and manage dependencies and this is another step toward a series of improvements that will make Gradle the gold standard for dependency management.

Getting Ready for 2.0 We’re getting ready for a transition to Gradle 2.0. What does this mean? It means that we’re going to be winding down a few features and options from 1.x that either haven’t gained traction of the community or which we think are unnecessary. We have a few candidates identified, but if you are depending on Gradle you shouldn’t be too worried that we’re going to cut off a good features.

Read the full release notes to get a sense of features we are currently deprecating, and please feel free to contact us via the Gradle forums if you see something being cut that you think we shouldn’t be.

We understand as a community that a project like Gradle can very easily just amass unnecessary and unused features over time. It’s dangerous to just leave a feature that isn’t used in a project like Gradle. It presents an opportunity for defects to creep in over the course of a project and it tends to add needless bloat to the tool. Just like we’re focused on saving you time with Gradle, we’re very focused on making sure that the tool is as efficient as it can be. Getting rid of the “cruft” during a major version upgrade is a healthy part of keeping Gradle lean.

Don’t Miss Gradle Exchange 2013

Are you in London at the end of October? If not, you should be. If you are, come check out Gradle Exchange at Skill Matter. Hans, Szczepan, Peter, Rene, Luke, and Adam are going to be there as well as Baruch Sadorsky, Evgeny Goldin, Marcin Erdmann, Thorstan Sommermann, and Johannes Rupprecht. This is a two-track, one-day conference dedicated to Gradle on Monday, October 28th, 2013 in London.

For more information and to register for Gradle Exchange 2013 go to http://skillsmatter.com/event/java-jee/gradle-exchange-2013

Get Trained by a Gradle Expert

Don’t miss our in-depth 3-day build-master classes delivered by one of the Gradle Core developers. We have upcoming classes in London and San Francisco, CA.

Good news on progress.

Just to note a minor matter. Like 1.7 there are multiple gradle-1.x/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction files in the *-all.zip at least (and maybe other redistribution files). Some differ and length and contents, so I guess they need to be handled in some way to merge/triage.

Yep GRADLE-2767 has been fixed in master, but the fix didn’t make it into 1.8. So this should be last release that has this problem. Thanks for reporting.

Maven Publish is still incompatible with Sonatype due to the lack of support for signing. Any workarounds?

You can always use the ‘maven’ plugin.

I’m under the impression that the maven plugin is due to be deprecated?

Not before the ‘maven-publish’ plugin is promoted from it’s incubating status.

But yes it seems I will just use that.