Avoid the fat-slf4j-jar and solve the logging issue in a better way

[TheSnoozer]

Hi @ktoso,
before I start working on this issue I wanted to recheck some couple of details.
With Issue #191 we got the Request that the plugin ignores MAVEN_OPTS=-Dorg.slf4j.simpleLogger.defaultLogLevel=warn
I have introduced the slf4j-dependency with #194.
However we got some class loading issue with some of the maven versions (#196, #198), which we fixed by creating a uber-jar (#197).

I just want to quickly recap what I could figure out during the phase I reported this to Maven (https://issues.apache.org/jira/browse/MNG-5835)
Let's start with the fact that MAVEN_OPTS=-Dorg.slf4j.simpleLogger.defaultLogLevel=warn mvn clean package and mvn clean package -Dorg.slf4j.simpleLogger.defaultLogLevel=warn are two complete different things :-)
The main fact is that the MavenCli considers the -D arguments passed to Maven after the SLF4J logger has already been initialised.

I think it's better to illustrate this with an example what the original problem was and what this all means:
Let's start with a simple Mojo just using the getLog()-Method for logging.
This will take care for MAVEN_OPTS=-Dorg.slf4j.simpleLogger.defaultLogLevel=warn mvn clean package. However it will ignore the -D arguments passed to Maven (so it will ignore mvn clean package -Dorg.slf4j.simpleLogger.defaultLogLevel=warn).
java // plugin one public void execute() { getLog().info("Info-Message: Hello, world."); }
Let's now move to a simple Mojo that create the getLog() outside the execute and will store it as a variable (that was the way the git-commit-id-plugin had done it's logging). The Problem here as outline in (https://issues.apache.org/jira/browse/MNG-5835)
If you call getLog() in your constructor then you'll get an instance of SystemStreamLog that unconditionally logs to System.out. Your mojo will be wired with an SLF4J-backed logger after construction. Call getLog() during the execute() method, and don't cache the value.
So in general this will ignore MAVEN_OPTS=-Dorg.slf4j.simpleLogger.defaultLogLevel=warn mvn clean package (as reported). It will also ignore the -D arguments passed to Maven (so it will ignore mvn clean package -Dorg.slf4j.simpleLogger.defaultLogLevel=warn).

java // plugin two private final Log logger = getLog(); public void execute() { logger.info("Info-Message: Hello, world."); }

We currently have the third option available on the market.
It used the the slf4-dependencies and wires itself to the slfj-simple-logger.
Our current solution takes care for MAVEN_OPTS=-Dorg.slf4j.simpleLogger.defaultLogLevel=warn mvn clean package and also takes care of -D arguments passed to Maven (so it will NOT ignore mvn clean package -Dorg.slf4j.simpleLogger.defaultLogLevel=warn).

The essence is if there is no one is using the mvn clean package -Dorg.slf4j.simpleLogger.defaultLogLevel=warn-Option we can just drop the fat-slf4j-jar and the dependencies to slf4j and will let getLog take care of the rest. However also outline in https://issues.apache.org/jira/browse/MNG-5835 it may be a bad idea to store to logger somewhere (in the LoggerBridge). I currently don't have a valid reason why not saving it somewhere, but this somehow we definitely need to test.
Questions/comments are welcome :-)

[TheSnoozer]

Solved by #233