On Wed, Jan 16, 2013 at 2:39 PM, Marcin Erdmann <[email protected]>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? > I think the main goal should be to have the dashboard merged before the 1.5 release in 6-8 weeks. I'm very much looking forward to it. Hans > >> >> 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 > >
