On Fri, Nov 4, 2011 at 9:49 AM, 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. For example > > Singe Project Build: > gradle build > :build > > gradle clean test > :clean: > :test > > > Do we log these after the root task is complete? Or when we start work on > the task's dependencies? > I would say after, but I don't feel strong about it. The dynamic output is for figuring out what is going on. The console output is for figuring out the history. > > I think we'd also want to log the names of those tasks that produce > logging output, whether they are root tasks or not. > Absolutely. I forgot to mention that. For example when there are compile warnings or failing tests. > > > > 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. > > > One option would be to log the entry points to a project (those tasks that > produce the publications referred to by a project dependency) in addition > to the root task. This way, we'd log: > > bar:jar > foo:build > bar:build > Good point. > > Another option would be to rework the default task ordering, so that we > try to complete as much work for a given project as we can before moving > on. Then, you'd naturally get: > > bar:build > foo:build > I'm not completely sure. But I think people would perceive this a less surprising in general. As we will never be able to guarantee this though we might still also show the entry points as you proposed above. Hans > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
