Gradle 1.4 release outlook

Old Forum
1

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.

2

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.

3

Never mind Jetty 7… Jetty 8 is the current stable release, but Jetty developers recommend you upgrade to 9: http://www.eclipse.org/jetty/documentation/current/what-jetty-version.html - an upgrade to the Jetty plugin would be nice! :slight_smile:

4

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.

5

I am curious about how this feature will work.

Does gradle look for the testng.xml file somewhere or something? Will you be adding a TestNG loader for the “src/test/java” dir or something?

Make TestNG use the new Gradle HTML test reports by default.
6

Good point. I hope that via Arquillian we can provide a stable long term solution for being up to date with the different containers.

7

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.

8

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.

Hope that helps!

9

I can’t get TestNG Gradle HTML reports done in gradle 1.3. Please point me a direction. Thanks.

10

What is the URL of the piece of source code on GitHub?

11

Sorry for the late answer.

task testNG(type: Test) {
    useTestNG { options ->
        options.parallel = 'methods'
        options.threadCount = 10
    }
    testReportDir = file("$testReportDir/testng")
    check.dependsOn testNG
}

This way I can have both JUnit and TestNG tests in the same module, but Gradle resports only tests run by JUnit.

12

Hi Hans

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.

Regards, Etienne

13

Hello Etienne, FYI: I think we track the described issue here: http://issues.gradle.org/browse/GRADLE-2484

cheers, René

14

Just a short reminder about these three issues:

GRADLE-1298 - Change in filtered resource not picked up by archive tasks *

GRADLE-1646 - Copy tasks do not consider filter/expansion properties in up-to-date checks *

GRADLE-1276 - processResources task considered up-to-date although its spec has changed

I suspect that all of them have the same root problem and GRADLE-1646 is considered a blocker. I tend to agree.

15

I just uploaded a fresh example application to GRADLE-1298. Please see the latest comment.

16

Looking forward to the solution to GRADLE-1956 with Arquillian. Any estimates?

17

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.

18

Is there any work in progress or plans to make a scalatest integration as seamless as junit or testNG?

19

Not currently. How could it be improved?

20

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