I think it would be great if we could tackle the problem of test aggregation in the near future. Let's provide some background here:
- Gradle has no concept of test aggregation or report aggregation in general build in. What you can do now: Add a report task in the root project and configure it by iterating over all subprojects and add their xml test results directory to this task. See for example the Gradle build itself: https://github.com/gradle/gradle/blob/master/buildSrc/src/main/groovy/org/gradle/build/TestReportAggregator.groovy. You could also use the ant junit report task for this purpose. Problems: - It is not straight forward to get such a generated report. - The generated report has no notion to which subproject a test report belongs. That makes it more or less unusable for larger projects as you don't know easily who is resposible, where to look for the class (if you don't have the full source tree in your IDE). - As far as I know Maven has a similar issue. Jenkins helps out here by creating aggregated report with a subproject affinity. But I think it should be a capability of the build system. It depends a lot on the specific organisational structure and the type of project whether you are interested in reports per subproject, aggregated reports or both. So Gradle should provide a nice toolkit to easily build what you want with a test report aggregation that automatically does the wiring for you and generates reports that have the knowledge of which subproject the report page belongs too. There are other aggregated reports where there is usually no subproject knowledge needed (e.g. javadoc). You can generate this pretty straight forward with Gradle already: See: https://github.com/gradle/gradle/blob/master/subprojects/docs/docs.gradle#L250 But it would be probably nice if this concept is also more baked in on a high level way. Not sure if it is worth trying to model the concept of aggregation independent of reports (e.g. uberjars, aggregating tasks in general). Being smart with aggregated reports will also make our future site plugin much more valuable. Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com
