maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <i...@ifedorenko.com>
Subject Re: SLF4J related issues
Date Tue, 06 Oct 2015 02:23:40 GMT
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message