On 16/01/2013, at 9:50 AM, Marcin Erdmann wrote: > The next iteration of my effort on build dasboard plugin is available at: > https://github.com/erdi/gradle/tree/reporting-improvements. > > Following is what has been done since my last email: > - added a plugin specific chapter to the userguide and a reference to it form > the table listing all incubating integration plugins in standard Gradle > plugins chapter; kept it really simple > - added a sample by simply taking the code quality sample and applying the > plugin in its build.gradle; the sample can be simplified in the future when > Test task implements Reporting > - made sure that all public stuff has javadoc > - added GenerateBuildDashboard task to the dsl guide > - rewritten BuildDashboardPlugin in groovy > - used JSoup instead of Jerry for parsing and verifying the contents of the > generated report; removed the test dependency on Jerry > - used UncheckedIOException instead of RuntimeException in > BuildDashboardGenerator > - used BufferedWriter in BuildDashboardGenerator > - explicitly used UTF-8 as the encoding when generating the report, also > added a Content-Type meta tag to the generated report; added using UTF-8 > encoding when parsing the report in tests > - added @Incubating to the plugin, task and BuildDashboardReports > - plugin class now keeps Reportings instead of Reportis and calculates the > set of input reports lazily when calling getEnabledInputReports() > > I believe that if no issues are found it's time for submitting a pull request.
Your changes look good to me. Thanks for this. > After the pull request is accepted I can have a look at the next step which > would be to make sure that Test task implements Reporting so that it's > included in build dashboard report. I wonder if we should change the plan a little. We've just added a `TestReport` task type that can generate the HTML report. The goal is that at some point we remove the reporting from the `Test` task type and use this task instead. To make this work well, we need to make some improvements to the task graph. These are the same improvements that are already in the spec. So, if you're interested, you could do something like this: 1. Make the task graph changes. There are two parts to this: schedule the dashboard task to run after the reports have been generated, without adding a hard dependency, and to automatically add the dashboard task to the graph whenever any reporting task is added to the task graph. 2. Change the `TestReport` task to implement `Reporting` so that it is included in the dashboard. 3. When the dashboard plugin is applied, add in a `TestReport` task and disable the test report in the `Test` task. 4. At some point later, once the above is stable, move #3 to the Java plugin and deprecate the test report in the `Test` task. Let us know what you think, and we can update the spec to flesh out some of the detail for the above. If you'd rather go ahead with some of the other stuff in the spec (or none of it), that's fine too. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
