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? > > 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
