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