Hi all, After our exchanges this week at ApacheCon Core I wanted to have a look at what avoided us to provide for exemple in 3.4 a colorised output...
1/ Looking at this I found several issues related to a missing export of classes from SLF4J: https://issues.apache.org/jira/browse/MNG-5787 https://issues.apache.org/jira/browse/MNG-5842 https://issues.apache.org/jira/browse/MNG-5845 I fixed it here: https://github.com/apache/maven/commit/dfed29cc664f0e8f2f06278ff70d3037caf147f0 I hesitate to do an integration test for this. It's not really difficult but does it make sense to do this only for this missing slf4j export? The fix is very small but the problem may be larger and highlight the fact that we have no control to verify that what we export is stable over the time. What we should have is like a Clirr (http://clirr.sourceforge.net) control but which should include all the APIs we are making visible to plugins. There is no simple solution to do this AFAIK. Any feedback/advice ? 2/ To come back to my original problem to provide colors in Maven console you can look at these for references: https://issues.apache.org/jira/browse/MNG-3507 http://www.aheritier.net/united-colors-of-maven/ https://emmanuelbernard.com/blog/2015/07/27/maven-color/ In theory the change isn't more difficult than this commit : https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=8cddea291c279130d437bcdf3337f16296558530 But sadly because of our usage of slf4j which has a known backward incompatibility issue between 1.5 and 1.6 versions it is quickly a nightmare because if a plugin has a direct or transitive dependency to a slf4j additional artifact in version <=1.5 it will fail because of the incompatibility like here [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check (checkstyle-check) on project maven-checkstyle-plugin: Execution checkstyle-check of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V [ERROR] ----------------------------------------------------- [ERROR] realm = plugin>org.apache.maven.plugins:maven-checkstyle-plugin:2.15 It seems to be the case for a lot of plugins which are always using maven 2.x artefacts like checkstyle : arnaud@Arnauds-MacBook-Pro:~/Code/maven/trunks/plugins/maven-checkstyle-plugin $ mvn dependency:tree -Dincludes=*:*slf4j*:* -Dverbose [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Apache Maven Checkstyle Plugin 2.17-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-checkstyle-plugin --- [INFO] org.apache.maven.plugins:maven-checkstyle-plugin:maven-plugin:2.17-SNAPSHOT [INFO] \- org.apache.maven:maven-core:jar:2.2.1:compile [INFO] +- org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:1.0-beta-6:runtime [INFO] | +- org.apache.jackrabbit:jackrabbit-webdav:jar:1.5.0:runtime [INFO] | | \- (org.slf4j:slf4j-api:jar:1.5.3:runtime - omitted for conflict with 1.5.6) [INFO] | \- org.slf4j:slf4j-nop:jar:1.5.3:runtime [INFO] | \- (org.slf4j:slf4j-api:jar:1.5.3:runtime - omitted for duplicate) [INFO] +- org.slf4j:slf4j-jdk14:jar:1.5.6:runtime [INFO] | \- org.slf4j:slf4j-api:jar:1.5.6:runtime [INFO] \- org.slf4j:jcl-over-slf4j:jar:1.5.6:runtime [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.289 s [INFO] Finished at: 2015-10-02T15:39:28+02:00 [INFO] Final Memory: 20M/336M [INFO] ------------------------------------------------------------------------ A common use case for plugins or there librairies may often to add slf4j additional artefacts to redirect to SLF4J the output of others logging librairies. Sadly we cannot know if the usage they have may be relevant and we have no solution AFAIK to blacklist some reps or to enforce the version of a library to use (or we have to expose all SLF4J artefacts from core and I'm afraid that it will be the source of too many others incompatibility issues. For now I don't understand why the fact to change the logging implementation enforces me to fix the slf4j conflict ( https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=4c293743765b46a382371f5789e769bcac89f450). It isn't required with master and I don't see how replacing slf4j-simple by log4j2 can increase our risk to have the slf4j backward incompatibility. How is it possible that it works in master ? Like discussed with Robert, Tibor, Hervé and Tamas for now it may be a good idea for 3.4 to always provide the classical package with the classical simple-logger and to provide another package/assembly including the colorised version which may allow people to easily give it a try. Thanks for your help. Cheers, -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
