On 17/01/2013, at 12:39 AM, Marcin Erdmann wrote: > > > On Wed, Jan 16, 2013 at 7:05 AM, Adam Murdoch <[email protected]> > wrote: > > 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. > > Do you think that what I currently have is worth of a pull request and > merging it in?
Absolutely. > > >> 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. > > I'm completely fine with that. Wasn't aware that the work on TestReport task > has already started (I can see in the repo that it's just a few days old). > > > 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. > > I'm happy to pick this up and updating the spec with more details would > probably make it much easier for me. It will be challenging because I never > did anything with task graph apart from using whenReady() in some of my > plugins so you should probably expect some questions posted to this thread as > I go. > > Just please keep in mind that I have some other tasks to complete in the > coming days and then I'm off to Madrid to speak at Greach so I won't be > picking this up before the week starting on the 27th of January. Therefore > there is no rush in updating that design spec. > > Marcin > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
