Starting with version 3.1.0 maven uses slf4j for logging.
This opens the gate for a lot of nice tweaks.
One of them is the ability to log using colors, matching the logging level.
maven: download the latest version from http://maven.apache.org/download.cgi.
For this article I have used version 3.1.0, the latest at this time, and the first one to support slf4j.
For earlier versions this will not work.
For this one you don’t have the freedom to take the latest and greatest, you should match what maven uses.
So check the slf4j version by looking for
The maven version I used here (3.1.0) uses slf4j version 1.7.4.
log4j: download the latest version from http://logging.apache.org/log4j/1.2/download.html.
For this article I have used version 1.2.17, the latest at this time.
log4j2: download the latest version from http://logging.apache.org/log4j/2.x/download.html.
For this article I have used version 2.0-beta8, the latest at this time.
logback: download the latest version from http://logback.qos.ch/download.html.
For this article I have used version 1.0.13, the latest at this time.
java-color-loggers: download the latest version from https://github.com/mihnita/java-color-loggers/releases.
For this article I have used version 188.8.131.52, the latest at this time.
java-color-loggers config files: download some minimal config files.
I have changed them so that the output looks like the default maven output, but colored. Of course, you can do a lot more, but this is not part of the scope of this post.
jansi (optional): download the latest version from http://jansi.fusesource.org/download.html.
For this article I have used version 1.11, the latest at this time.
- disable slf4j-simple
- add the new slf4j binding libraries
- add the new logging configuration file
- configure the color libraries
Go to the
<mavenDir>/lib folder and move/rename
slf4j-simple-1.7.4.jar (I have created a subfolder named
disabled and moved it there).
Add the new slf4j binding libraries, color libraries, and config files
Decide what logger you want to use and then copy the following files in the right places.
The .jar files go to
<mavenDir>/lib/ext (and I have colored the versions red to show that they might change).
The config files go to
For this article I am only focusing on “the color part” of the logging.
For more advanced features (filtering, logging to files, etc.) you need to go to the official
documentation of the logger used and see what/how you can configure more.
Of course, you can use any other logging that has slf4j binding.
log4j folder structure
lib/ext/ lib/ext/slf4j-log4j12-1.7.4.jar (from the slf4j archive you downloaded) lib/ext/log4j-1.2.17.jar (from the log4j archive you downloaded) lib/ext/color-loggers-184.108.40.206.jar (no colors without it) jansi-1.11.jar (optional, see “Windows notes”) config/logging/ log4j.properties (or an equivalent log4j.xml)
log4j2 folder structure
lib/ext/ log4j-api-2.0-beta8.jar (from the log4j2 archive you downloaded) log4j-core-2.0-beta8.jar (from the log4j2 archive you downloaded) log4j-slf4j-impl-2.0-beta8.jar (from the log4j2 archive you downloaded) config/logging/ log4j2.xml (or an equivalent log4j2.json)
logback folder structure
lib/ext/ logback-classic-1.0.13.jar (from the logback archive you downloaded) logback-core-1.0.13.jar (from the logback archive you downloaded) color-loggers-220.127.116.11.jar (optional, see “Configure the colors”) config/logging/ logback.xml (or an equivalent logback.groovy)
Configure the colors
If you use log4j2 or logback and are happy with the default colors, stop here, you don’t have to do anything,
and you don’t need java-color-loggers.
mvn install (or whatever you normally do with maven :-).
Bingo! You should get colored output now!
Two loggers (log4j2 and logback) already have color support, but (at this point) they don’t allow you to customize them.
Here are the default colors:
|fatal||no such level in logback||fatal|
|error||error (bold / intense)||error|
|warn (brown)||warn (dark red)||warn|
Now, that we have colors, it becomes visible that some of the maven messages don’t go through the logging mechanism
(the reports about downloaded plugins, junit results), or are logged with debatable levels
(for instance should ‟Compiling X source files to …” be
INFO, or more like
And if you run with
-X switch (to enable full debug logging) the results are also not colored,
meaning they don’t go thru logging (should be with
DEBUG level, right?)
Same for the unit test results, no colors.
Personally, I also think it would be nice to be able to reduce the maven output :-)
So I have tried changing the logging level to
Seems OK, but I am not sure if I am not missing something important.
Anyway, I think this is a big step forward, and things will only get better and cleaner from here,
once more and more maven plugins start using slf4j for logging.
In the Linux/UNIX/Mac OS X world, this is enough.
In the Windows world you will need something to interpret the ANSI escape sequences and convert them to color.
You have several options:
- Use ansicon (https://github.com/adoxa/ansicon/releases
Copy it somewhere and enable it by running
ansicon -I(that is an uppercase i)
- Use an alternate console. Some consoles that support ANSI escapes:
- Use Jansi (http://jansi.fusesource.org/)
Method 1 is painless, I have used it for a long time and had no problems whatsoever.
And has the advantage that will give you ANSI escape support for everything else (C/C++, Perl, shell scripts, etc.)
Method 2 also gives you ANSI support for everything else, but since it replaces the original Windows console,
you might discover that the behavior is different at times, and some things might break (I don’t say they will, but they might).
Cygwin is a completely different ballgame, as cmd.exe is replaced by a UNIX/Linux shell, with all the tools.
Each of these alternate consoles have many extra goodies over the Windows console, not just support for ANSI escapes.
Method 3 is the least intrusive one, as it uses the standard Windows console, with cmd.exe, and only affects your
Java running (heck, it only affects your maven run, not even the applications tested inside maven, for that you will need to jump thru some
If you are afraid to break anything, this is the way to go.
On the ‟cons” side: it adds yet another dependency, it runs native code using jni from DLLs extracted at runtime
(sometimes leaving some ‟junk” in your temp folder, or having antiviruses complain), does not help you with other programming languages.
And this is what makes jansi optional.