On 27/11/2012, at 7:24 AM, Marcin Erdmann wrote: > Just to let you know, I'm currently pretty busy with preparing a talk for GGX > in December so I won't be able to have another go at that before Christmas.
Thanks for letting us know. There's no rush - whenever you get to it is fine. > > Marcin > > On 11/16/2012 05:44 PM, Luke Daley wrote: >> On 15/11/2012, at 7:39 PM, Adam Murdoch wrote: >> >>> On 15/11/2012, at 10:35 PM, Luke Daley wrote: >>> >>>> On 15/11/2012, at 6:32 AM, Adam Murdoch wrote: >>>> >>>>> On 15/11/2012, at 10:06 AM, Marcin Erdmann wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I've started working on some stuff based around the design spec >>>>>> @https://github.com/gradle/gradle/blob/master/design-docs/reporting.md >>>>> Excellent. >>>>> >>>>>> and have a few questions that don't seem to be covered in the spec. >>>>>> >>>>>> You can have a look at the code I managed to produce in my fork in >>>>>> reporting-improvements branch >>>>>> (https://github.com/erdi/gradle/tree/reporting-improvements). Basically >>>>>> it's just a sketch of the task with only inputs and outputs specified >>>>>> and without any implementation. The plan was to see how far I could get >>>>>> without any major conceptual problems. Obviously I plan to add tests to >>>>>> it when I'll find the answers to my questions. >>>>>> >>>>>> The following are the problems/questions I have: >>>>>> >>>>>> - Test task doesn't implement reporting so it won't be picked up by the >>>>>> plugin when collecting all the reports to be put in the build dashboard >>>>> I forgot to put that in as a story. We'd need to either: >>>>> >>>>> * Change Test to implement Reporting, or >>>>> * Split out a separate TestReport task that implements Reporting, or >>>>> * Have GenerateBuildDashboard task know about Test task type. >>>>> >>>>>> - given the fact that GenerateBuildDashboard task should take a set of >>>>>> Report instances as input (as per design doc) it is impossible to >>>>>> generate any useful information in the build dashboard report about the >>>>>> reports apart from the name (which is usually html, xml or text) and >>>>>> path. It is impossible to link a report to a task that has generated the >>>>>> report. >>>>> Why do you want to link a report to a task? To get a better name for the >>>>> report? Or something else? >>>> The viewer needs to understand what the report is. How else are you going >>>> to differentiate between the “test” and “integTest” reports? >>>> >>>>>> Should we use Reporting instances as input to GenerateBuildDashboard >>>>>> task and add something like getName() method to the Reporting interface? >>>>>> Or should we assume that Reporting (probably should be called >>>>>> ReportingTask then) will only be implemented by tasks and get a >>>>>> meaningful name for the sections of build dashboard from the path of the >>>>>> task? >>>>>> >>>>>> - should all files from the enabled Reports passed as the input to >>>>>> GenerateBuildDashboard task be used as @InputFiles for that task? The >>>>>> obvious choice for outputs seems to be the build dashboard html file >>>>> The contents of the files aren't really inputs to GenerateBuildDashboard. >>>>> It's the destination path that is the input. That is, if the check style >>>>> report is moved from build/reports/checkstyle.xml to >>>>> build/checkstyle/report.xml, then we need to regenerate the dashboard >>>>> report. But, if the contents of the check style report changes, then the >>>>> dashboard report doesn't need to change (at this stage). >>>>> >>>>>> - how should the public api of GenerateBuildDashboard task look like? Is >>>>>> something like that ok: >>>>>> >>>>>> task generateMyDashboard(type: GenerateBuildDashboard) { >>>>>> aggregate reportingInstance1, reportingInstance2, ... >>>>>> } >>>>> That looks fine. >>>>> >>>>>> - what should be used to actually generate the html of the build >>>>>> dashboard? A templating engine, builder etc.? >>>>> What would you like to use? It has to be fast, as this report, when >>>>> enabled, will be generated for pretty much every build. >>>> I like the concept of http://code.google.com/p/jatl/. I don't know what >>>> the quality is like. I think this would be the sweet spot, a strongly >>>> typed builder. >>> Might be a good option. Does it work with Java 5? >> According to the POM it is: >> http://code.google.com/p/jatl/source/browse/pom.xml#198 >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
