On 10/11/2010, at 9:47 AM, Tomek Kaczanowski wrote: > Hello Steve and All, > > some ideas and questions regarding profile (--profile) that was > introduced in gradle-0.9-rc2. > > First of all it is very nice. :) > > Second, I would be happy to implement other outputs. For me HTML is an > overkill, I would like very much to have something simpler - txt would > be great. Coding seems trivial, but the question is "how it should be > done" so the users are happy. > > Let us assume that we have not one reporter (as it is now) but three > of them: HTML, TXT and CSV. > > Now what should gradle do when invoked with --profile: > 1) run all of them > 2) run a default one > > If 1 then probably a dir with profile_DATE should be created and all > generated files should go inside. > > If 2 then how could user define another reporter if the default > doesn't suit her/him? Another switch, like > gradle sometasks --profile --profileFormat=txt > ? > > Any thoughts?
I think we should use tasks instead of command-line options. That is, get rid of the --profile option and add a bunch of profile reporting tasks. Some advantages: * You can specify which formats you like by listing the tasks on the command-line: gradle htmlProfile txtProfile * The reporting is not baked into the core (the instrumentation is, but, as discussed in another email, we will merge the instrumentation into the progress reporting infrastructure). * I can add my own reporting tasks * The reporting tasks are available in the build script for me to configure, add actions to, dependOn, etc. * The reports will be integrated into whatever reporting infrastructure we add. Very similar reasons as to why 'gradle --tasks' was changed to 'gradle tasks' -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
