Another update - I picked it up again and progress looks good. I have a
very simple, unstyled but fully functional dashboard report generated,
but I need to add more integration tests to the implementation (basic
ones are already there and passing). Will share it with you in the
coming days to hopefully get some feedback and directions where do we
want to take it from here.
Marcin
On 11/26/2012 10:22 PM, Adam Murdoch wrote:
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
