On 07/01/2013, at 10:15 PM, Marcin Erdmann wrote: > 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.
Great stuff, looking forward to it. > > 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 >> > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
