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.
I'm not keen on a template based solution.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
