On 04/11/2011, at 10:25 PM, Luke Daley wrote: > One thing to keep in mind, less is not more for some people. > > Grails 2, inspired by Gradle, got much more concise when it came to its > console output. This is generally ok, but is already proving problematic when > things go wrong.
This is a good point. We do have a few options here. One would be to write diagnostic stuff to the console when things fail. Another would be to improve the error messages. Another would be to write a diagnostic report to a file on failure (actually, these are really just the same option). Another option is to not be quite so minimal. For example, we could log the lifecycle tasks and leave out the worker tasks. This might be a good next step, where we would show about 1/4 the number of tasks, and can try out usability tweaks for when things go wrong, without losing the high-level structure of the build from the console. > I don't have an answer here, but one thing we need to make sure of is that > people can readily understand what's happening. That's ultimately more > important than conciseness. > > On 04/11/2011, at 7:58 AM, Hans Dockter wrote: > >> I would like to see a reduced console output in Gradle. Thanke to our >> dynamic output we don't need to abuse the actual logging anymore to be a >> progress bar. >> >> Why not do the following by default: Show only the root tasks per project >> that were executed. For example >> >> Singe Project Build: >> gradle build >> :build >> >> gradle clean test >> :clean: >> :test >> >> Multiproject Project Build in foo(foo depends on bar): >> >> gradle build >> :bar:jar >> :foo:build >> >> gradle buildDependent >> :bar:build >> :foo:build >> >> This would avoid in particular the clutter of using buildSrc. Of course if >> you have no console than enables dynamic output we should switch back to our >> current way of logging. >> >> One challenge I see with implementing this is the order in which thing are >> displayed in a multiproject build. Right now we have: >> >> ... >> :bar:jar >> ... >> :foo:build >> ... >> :bar:build >> >> But to only show the following in that order would be confusing: >> >> foo:build >> bar:build >> >> As the dependencies between foo and bar are the opposite. >> >> Hans >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
