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? -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
