And if you guys *do* take a template-based approach, don't forget to consider https://code.google.com/p/aluminumproject/ ;)
2012/11/15 Marcin Erdmann <[email protected]> > On 11/15/2012 11:35 AM, 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<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<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. >>> >> I think we're better of going for the cleaner solution which in my > opinion are options 1 and 2. It's a bit too major task for me to implement > any of them so if you don't mind I'll ignore it for now and hopefully > someone on the core team will be able to do it. > > >>> - 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? >> > Exactly that's why I believe we need to link reports to tasks. > > >> 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). >>> >> Good point. > > >>> - 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. >> >> > JATL looks promising. I will investigate it and check how clean and well > tested the codebase is. > > > ------------------------------**------------------------------**--------- > To unsubscribe from this list, please visit: > > > http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email> > > >
