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 -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
