On 05/11/2011, at 7:07 AM, Hans Dockter wrote: > > > 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 in, when you run --dry-run, show all the tasks, as we do now? > > > * 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. I wonder if the profiling report might be a better solution for this use case, as it already shows all the tasks, plus their up-to-date-ness. Perhaps we just need another 'timeline' tab that shows what happened when. Combine this with some history, and we probably have a pretty good solution. > > > 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? Yes, we should. I just don't want to reduce it too much. > > 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 > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
