We are already looking forward to the Gradle 1.6 release.
Some of the key features we are tackling include:
Provide an incremental build API to enable tasks to query what has changed in regard to its inputs and outputs. Work has already started in master. - Extend the Tooling API to capture the need of Android projects to enable better IDE integration. Work has already started in master. - Starting work on the Gradle Plugin Portal to improve the experience of publishing and using 3rd party plugins with Gradle. - The Gradle Bootstrap plugin will be polished and released as an incubating feature, allowing automatic POM conversion for simple Maven projects. Work has already started in master. - Make it easy for to produce multiple outputs per source set, such as different variants for an Android application, or libraries targeting different runtimes (eg Groovy-1.8 and Groovy-2.1). See the design doc. Work has already started in master. - The current ‘Jetty’ plugin is limited in scope and ability. We plan to commence work on a full-featured ‘Gradle Deployment Plugin’ backed by Arquillian. - Add a JaCoCo Code Coverage plugin to the Gradle Core. Work has already started in master. - Support for JUnit categories. Work has already started in master. - Provide a richer DSL for describing task dependencies. For example you will be able to define that if two tasks are going to be executed, one should run after the other, without creating a hard dependency between the two tasks.
We’ll also be tackling some bug fixes:
The number of community contributions we receive for Gradle continues to increase. In 1.6 we’ll be working to incorporate more of the pull requests we get from our fantastic community members. We are very grateful to everyone who contributes, from small documentation fixes to major new plugin developments.
Of course, we may not find the time to do all of the above, and if time allows there is plenty more we’d like to tackle.
Several of the features and bug fixes are in progress and some are already functional. We work hard on maintaining backward compatibility, so why not try out the latest Gradle Nightly instead of waiting for Gradle 1.6. We update all of our documentation as we go, so you can always see what’s been completed in the Gradle Nightly Release Notes. Your early feedback would be most appreciated.
There are plans for Groovy 2.1 support, but they are not in the priority list for 1.6.
The complication is that this is a breaking change, so we need to put a migration plan in place rather than just switching from Groovy 1.8.6 to 2.1. The current plan is that we’ll add support for publishing plugins built for multiple Groovy versions and offer a way to select between a Groovy 1.8.x based Gradle runtime and a Groovy 2.x based runtime.
In the next major Gradle release, we’ll be able to switch the default to the latest Groovy version, while still allowing you to choose from a set of supported Groovy runtimes.
We’re integrating andrews plugin. Andrew was so kind to do some rework on his plugin and send us a pull-request (https://github.com/gradle/gradle/pull/138) to integrate it into the gradle codebase . We’re currently in the process cleaning some stuff up related to that and add documentation. The current master contains already a working jacoco plugin. We encourage everybody who’s interested to do some trials and give us feedback. You can grab the latest nightly at http://www.gradle.org/nightly. If you can wait another day, the nightly also contains a userguide chapter about the jacoco plugin.
I’m currently using Andrew’s plugin (using the buildscript closure), but I’ll try the nightly and see how it works (in a few days). I’m mainly using jacoco with sonar (the new sonar-runner plugin, which means I need the *.exec files and the JacocoMerge type of tasks).
The documentation is great, but the black backgrounds in the code portions use a lot of ink and do not print legibly. Hope future versions of the doc will use a more printer friendly format.
In the process, we also hope to make Arquillian easier to use from Gradle for testing, though that’s a general desire and not necessarily in the scope of this work.
I have not studied the details but I would like to see support for integration tests (IT) as part of the jacoco plugin. Is that possible?
In my multi projects, I have a few projects executing integration tests based on code base of core and component source code from other projects.
Currently I fetch exec files from remote servers both by invoking the tcpserver port of the application and by fetching exec files from completed commands. Then i merge them into one file and provide that to the sonarRunner as IT coverage.
I think a good feature would be to apply the jacoco plugin and configure it as IT type, configure which tasks to be run (I don’t think the test task is the right one for IT) and which files to be collected afterwards.
Hi, in the effort to enhance the integration with IDEs, please consider also those long standing problems with the Eclipse IDE integration regarding web applications!! I mean, for example, GRADLE-2123, GRADLE-2396 and GRADLE-1422 (which I think are all strictly related).
Will it be developed from scratch? or you’re integrating this one: