On Fri, Nov 4, 2011 at 8:47 PM, Adam Murdoch <[email protected]>wrote:
> > 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). > I don't see how this necessarily helps you when things go wrong. The interesting question for me is what is the relevant output. I like to see tasks, specially the lifecycle tasks, as something that leaves the project with a certain state or with a certain output. So you could argue that it might make sense to show all the states the project is in. Originally I though this is not necessary. And it might be not necessary if all the projects just use the standard lifecycle. But if projects have special lifecycle tasks that are also aggregated by build, then I guess it would make sense to show them. So may be we should show the lifecycle tasks. But I'm not sure. In the case of buildSrc for example I still think this is too much clutter. Hans > 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 > >
