ok I will do some tests in that direction to see if I can find a solution. Clearly I would like to be able to break maven logging by just adding an extension jar including a simple logger.properties. If it is the case we need to fix it. But have a way with a distinct/specific file to do it may be a good thing if it allows us to write an extension to override/extends the default logging to add colors, use an appender to send logs somewhere else …
Thanks for these valuable feedbacks > On 07 Oct 2015, at 15:36, Igor Fedorenko <[email protected]> wrote: > > From what I can tell, alternative logging backend can be distributed as > an extension that is dropped into M2_HOME/lib/ext folder. > > The only real limitation is that you can't provide default logging > configuration as part of the extension. This is due to odd/wrong order > of entries in m2.conf file, but I didn't feel too strong about fixing > it. https://issues.apache.org/jira/browse/MNG-5836 > > -- > Regards, > Igor > > On Wed, Oct 7, 2015, at 08:39 AM, Arnaud Héritier wrote: >> Hi Igor, >> >> I didn't know this part of the code. It seems to be the right place to >> do >> it like you did here : >> https://github.com/takari/io.takari.m2e.lifecycle/blob/master/io.takari.m2e.incrementalbuild.core/src/io/takari/m2e/incrementalbuild/core/internal/MavenComponentContributor.java >> >> Thus in that case what we should do is to replace for a plugin all >> slf4j >> artifacts in version < 1.6 it may have in dependency to use a version >> 1.7.x >> like our core. >> >> It may me think that the colorized logging may be perhaps distributed >> as >> an extension ? >> >> cheers >> >> >> On Tue, Oct 6, 2015 at 4:23 AM, Igor Fedorenko <[email protected]> >> wrote: >> >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> ----- >> Arnaud Héritier >> http://aheritier.net >> Mail/GTalk: aheritier AT gmail DOT com >> Twitter/Skype : aheritier > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
