On 26/03/2012, at 9:20 PM, Mike Mills wrote: > One thing I have found with those tools when used with our Ant build, > was that on a build that is less than a minute generating xml and html > reports for each of those three tools adds quite an overhead to the build. > > In general humans want the HTML, and CI wants the XML, so if there is a > way to determine the most likely output that could help. > > Personally I would like to be able to see output to the cmd line from > those plugins as the default as that saves me from firing up a browser > to read the error.
Same here. This will happen at some point. In addition, we might add an 'open' task rule, which opens a given report in the browser. e.g. I can run 'gradle openTestReport' to open the HTML report of the 'test' task. > > -Mike > > On Mon, Mar 26, 2012 at 7:51 PM, Luke Daley <[email protected]> wrote: >> Should we create issues? At least for the two dot points? >> >> Begin forwarded message: >> >> From: Gradle <[email protected]> >> Subject: New idea: make code quality plugins coherent, and separate xml and >> html ... >> Date: 22 March 2012 10:38:28 AM GMT >> To: [email protected] >> >> jnizet just shared this idea in Gradle: >> >> make code quality plugins coherent, and separate xml and html reports >> >> I tried using these three code quality plugins: findbugs, pmd, and >> checkstyle. All basically do the same things: use a config file, check the >> source or byte code, and generate reports. However, they don't follow the >> same rules: >> >> - checkstyle needs a config file to be present, and makes the build fail >> otherwise. The other two plugins use a default configuration. >> - findbugs generates xml OR html. PMD generates both by default. Checkstyle >> generates only XML. They should all be able to generate both types, IMHO, >> and should have the same default >> >> Moreover, I would find it much cleaner to have html reports generated in a >> html subdirectory, and xml reports to be generated in an xml subdirectory. >> This would make other tasks (publishing to sonar, zipping, etc.) easier to >> develop. Moreover, if other future plugins (please support cobertura!) adopt >> the same strategy, it will be even more important because they might >> generate a whole lot of xml and html files. Cobertura, for example, >> generates one html file per class. >> >> Reply | Notify me when people reply >> >> ________________________________ >> >> This message sent from the Gradle community on Get Satisfaction. >> To unsubscribe or change your email settings, click here. >> >> >> ---------------- >> >> Create a customer community for your company at GetSatisfaction.com. >> >> >> -- >> Luke Daley >> Principal Engineer, Gradleware >> http://gradleware.com >> > > --------------------------------------------------------------------- > 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
