Improving Console Output


(Hans Dockter) #1

summary: Make the output more minimal, dynamic and colorful. Use build history for better and dynamic progress reporting. status: Discussions are happening and we will iteratively add features in this area after 1.0. code: planned

We think compared to other Java build systems Gradle already does a nice job regarding its console output. But we are just at the beginning. We want to make it more minimal, dynamic and colorful. We have all the build history to provide very interesting dynamic information (e.g. progress report based on how long a task/build took the last time, …). We think one reason for the very verbose output of many tools is that this output acts as a kind of primitive progress bar. In the future, all Gradle progress information will be transient. The only thing that will be seen after the build has finished are the actions that really did something (because of our incremental build richness we know that). All the dynamic output will be based on a generic event system (as it is already). So an IDE plugin can also hook into that event system.


(Matias Bjarland) #2

As you are looking into the console user experience, I would raise a +1 for making it possible to do clean console input handling as well. I know a lot of people discard console input as something you should not do in a build, but I find that approach a bit narrow minded. I think an intelligent build system which can, when needed, ask a couple of questions from the building user (where is your jboss installation located, etc) is a good idea.

See GRADLE-1147 for an example where this is not that optimal in the current gradle implementation.

Also, as the gradle daemon becomes default, System.console() will no longer be available (since the daemon is not attached to a console). Will we then lose console input altogether? I would find this most unfortunate if so.


(Łukasz L.) #3

I think it would be nice to make the statuses (> Loading) work also on cygwin console, as they do for windows console - is it planned/reported somewhere?


(Paul van Leeuwen) #4

hi, I experience also ugly output when running from PowerCMD (I guess similar experience to the previous comment about cygwin : for me the “> Loading” / “> Building” is printed many times in the output). Don’t get me wrong, from the windows command prompt when seen by a human it is nice / fancy, so congrats. Though, I would just appreciate the option (e.g. command line flag) to get the normal output (or quite, info, debug, for me that is regardless), but without “> Loading” / “> Building” being printed at all. Personally I would not miss it and it does complicate some uses of gradle (stream listening, different command lines).

This topic is also discussed here: http://forums.gradle.org/gradle/topics/the_loading_and_building_status_indicators_possible_to_stop_displaying_those


(Łukasz L.) #5

currently for Cygwin I can’t see any statuses with “>”, not even printed somewhere between tasks. I agree it would be nice to be able to switch them off in general (for the reasons you gave) but my comment meant to ask for them to BE present on Cygwin :slight_smile:


(Szczepan Faber) #6

Not sure if this greatly contributes to improving the console output but I thought I’d share. With the coming release you would be able to configure the visibility of the test output at the console: http://forums.gradle.org/gradle/topics/seeing_test_output_at_the_console


(Saager Mhatre) #7

Agreed. In fact, I’d go so far as to say that as with human-friendly output, we should also have an option to generate machine-friendly output that other tools could consume.


(nm2501) #8

At the moment when I use an ‘Exec’ task, all the coloured standard output of the executable is converted to grey. I’d like to see Gradle preserve the original colouring if that’s at all possible. (I’m using Windows 7 by the way.)