Description
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 :-)