It is possible to use ClassRealmManagerDelegate to replace "bad" slf4j-related plugin dependencies with compatible "good" dependencies. This is what I do in my "better multithreaded logging" maven extension and it works quite well from what I can tell.
-- Regards, Igor On Sun, Oct 4, 2015, at 10:38 AM, Arnaud Héritier wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
