We are already looking forward to the Gradle 1.4 release.
Some of the key issues we are tackling include:
Performance and memory optimizations in various areas. - For the dependency insight report we layed the ground work to configure task properties from the command line. We now want to expose command-line task configuration as an incubating feature. (design doc) - When Junit/TestNG tests generate a lot of test logging this currently might lead to a high memory footprint as part of generating the reports. We will significantly reduce the memory footprint of test report generation.
Fix GRADLE-2364 - Don’t delete changing artefacts in the cache before checking if changed. When run with --offline this corrupts the cache. - Fix GRADLE-2175 - Treat snapshot classifier artefacts (e.g. core-1.0-SNAPSHOT-sources.jar) as changing. This is in particular important for IDE integration. - Fix GRADLE-2512 - Issue a warning when mutating task properties after it has started executing. For example when doing: ‘task foo << { dependsOn bar }’ - Continue work on the new incubating publication DSL (this will also lay the foundation for a satisfying solution of the “Maven Provided Scope” use case). See also the design-doc.
add support for publishing Maven modules.
add support for customizing the identify of a publication, i.e. (org, module, revision) or (groupId, artifactId, version) dependending on the publication type. - Make TestNG use the new Gradle HTML test reports by default.
There is more we might tackle if time allows or we may not find the time to do all of the above. As always, we will be working on resolving a mix of smaller bugs and issues. We will also be working to incorporate some of the pending pull requests received from our fantastic community members.
We have also started experiments together with the folks from Arquillian to use Arquillian for deploying with Gradle (for testing and releases). Arquillian provides deployment support for a wide range of containers. Amongst many other good things that would solve woes like the Gradle Jetty plugin not supporting Jetty 7 yet.
Those all look like great features, but are the issues with the daemon (at least on Windows) on the docket anytime soon? I’d like to start promoting it, but issues like GRADLE_2415 make me hesitate.
It would be great if those changes enabling configuration of task properties would lead to the ‘run’ task of the application plugin being able to forward any additional command line arguments to the executed application as the args array of the its main method.
We don’t know yet when we will tackle this issue. Not that we don’t think it is not important. But so far for the 1.4 stream other issues had higher priorities.
With Gradle 1.3 you can already configure TestNG tests to generated the neat Gradle HTML test reports. You can peek at the implementation in the source code. In 1.4 we want to make this behavior the default.
Implementation-wise, we simply stop using TestNG reporters, instead we make Gradle generate the report, reusing the machinery we already have for JUnit.
We noticed a problem with Gradle’s reporting of @Ignore(d) test files (ignoring test methods works fine). Ignored files are not present in the reports. We observe this via TeamCity integration.
It would be great to have this fixed in the context of the test improvements of 1.4.
I kind of grew cautious with estimates. There are just too many factors. What is pretty reliable is the outlook we are providing for every release. So it is safe to say that it will be not part of 1.4 (released beginning of January). It might be part of 1.5 or provided as an external plugin during the 1.5 stream. We consider this as high priority.
gradle could find the tests/specs the same way as it does for junit or testNG (without configuration, just putting them over src/test/scala), produce the same reports as it does for the others… and so on… today, the way I’ve found to run my tests with scalatest and gradle is following what is described on this issue http://issues.gradle.org/browse/GRADLE-1032