I like the idea for cleaner & tidier output. Seeing all tasks is handy at times, though. When I run the build without '-i' and the build fails. Sometimes the key to debug the problem is to understand in what order the tasks executed. Especially if my build adds some task dependencies (implicit/explicit). I could rerun the build with different logging but sometimes it can be time consuming. Perhaps we could print some tasks in one line or use some ascii art to make the view 'nicer'. Though, I must say usually seeing all the tasks is just clutter so I won't cry if they go away from the default view.
--dry-run use case Adam mentioned is very important. I even teach it during the classes and I use it very often. Ideally, I don't want to be forced to couple --dry-run with finer log level (e.g. '-i') because the output is not as nice in that case. It includes some other stuff not useful for the analysis of the execution order. IMHO, whatever we change in the default output we should not remove the solution to this use case (or provide alternative solution, obviously :). Cheers! On Fri, Nov 4, 2011 at 9:07 PM, Hans Dockter <[email protected]>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 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 >> >> > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
