On 07/10/2010, at 9:45 AM, John Murph wrote: > René, > > I think that's a terrible idea. Mostly because you use Hudson, however. I > spit in Hudson's general direction! :) > > In all seriousness, different formats might be interesting. We use TeamCity > (hence the Hudson jabs above) and I know it can show custom reports, but I > don't remember how. Mostly, this just means that the profiler needs to have > a "report generation strategy" that can be changed. More work for Steve, yay! >
I would think about moving the reporting (but not the instrumentation) to a task. There are a few reasons for this: * It would be possible to replace the report implementation. I recently changed the --tasks, --dependencies and --properties options to simply look for a task with a well-known name in the project (they used to create an instance of a hard-coded type). The motivation was for something else, but a side-effect of this is that the implementation of each report is replaceable. The same thing could happen with the profile reporting, where 'gradle --profile <tasks>' is an alias for 'gradle <tasks> profileReport' * It would be possible to configure the report (task) programmatically. Say, from an init script or build script. Or plugin or whatever. * It would be possible to configure the report (task) from the command-line. I just added some very rough infrastructure for configuring task properties from the command-line. For example, you can do 'gradle tasks --all' where '--all' is mapped to tasks.showDetail = true. The same thing could happen with the profile reporting. * It would be possible to generate multiple reports by, say, adding dependencies to the report task. -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
