On Fri, Nov 4, 2011 at 8:56 PM, Adam Murdoch <[email protected]>wrote:
> > On 04/11/2011, at 6:58 PM, 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. > > > There are a few things I use the logging for. I'd like to have > replacements for these use cases if we were to make this change: > > * With --dry-run, to see exactly which tasks will be executed for a given > Gradle invocation. The tasks report does show the task dependencies, but > that's not quite the same thing, as I don't want to flatten the graph in my > head. > That is a good point. But --dry-run is already a kind of debug mode. So we could associate it with a different log level in any case. > > * As a build author (and a Gradle author), it gives me a feel for whether > the build is doing too much stuff - ie running unexpected tasks, and more > importantly, whether stuff is considered up-to-date when it should be. > Yes. But for me the main scenario is the normal dev triggering the build for his enterprise build. I guess we would add additionally log-levels to still provide the granularity we have today as lifecycle logging. > > In both these cases, the progress bar doesn't really help me. It's the > fact that this information is permanent that helps me here. > Right. BTW: Is it your general opinion that we should reduce the logging output for the default use case or not? Hans > > 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 > > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
