Hi,

Why do we have to force our users to a specific logging implementation
than we choose ?
We can propose variants and at least one as a workaround to maybe fix
sonar issue.

So what I do in the branch called dynamic-logging-impl is a "dynamic"
way of loading the implementation users prefers (default is log4j2).
It's just a matter of modifying MAVEN_OPTS="-Dmaven.logger.impl=log4j2
or slf4-simple or logback" (and thanks to our home made "osgi"
classworld :-) )

Note: with this implementation is possible to use any other slf4j impl
you want (IMHO good enhancement for ci servers which want to route
logs somewhere)
It's just a matter of adding a realm in m2.conf

[thegreat-new-a-la-mode-slf4j-impl]
load       path to my great new slf4j impl/*.jar

Then
MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"

Anyway just tested with sonar and
[ERROR] Failed to execute goal
org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
project hello-world: Can not execute Sonar:
ch.qos.logback.classic.LoggerContext cannot be cast to
ch.qos.logback.classic.LoggerContext
I always love such classloader message :-)

So I need to investigate a little bit more but not so far from having
that for sonar
BTW works fine for classic use case.

If you want to test that a build is available here:
http://people.apache.org/~olamy/maven/dynamic-logging-impl/

2012/12/1 Jason van Zyl <[email protected]>:
>
> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <[email protected]> wrote:
>
>> Hi Jason,
>>
>>  Couldn't we have a look at olamy's log4j2 branch to see if we could
>> sanitize / merge it to propose at least one change for the end user
>> and demonstrate the interest of the change about logs : a colorized
>> console.
>
> Not without discussion about the implementation. To me the obvious choice is 
> Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a 
> discussion. I've been working on the release but I plan to make a branch 
> using Logback so we have a basis for discussion.
>
>>
>>  I remember you did that in mvnsh/teslashell a long time ago (as an
>> extension ?) and perhaps it could be easy to add properly this feature
>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>
>>  Myself I'm using a 3.1.0 fork with this patch and I' m really
>> satisfied (it's so good to quickly see highlighted warning and errors
>> ). I merged it back in the last 3.1.0 tag you did without issue
>>
>>  Wdyt?
>
> Just as easy with Logback, the only difference being Logback is a mature 
> solution. So I'm sure there's going to be a discussion.
>
>>
>> ---------
>> Arnaud
>>
>> Le 1 déc. 2012 à 00:20, Jason van Zyl <[email protected]> a écrit :
>>
>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>
>>> Anyone want to add anything or discuss anything before I spin this? I'm not 
>>> in any rush so if folks want to talk about logging we can. But given the 
>>> fact once SLF4J initializes it can't change the implementation plugins 
>>> integrating with Maven need to use the implementation we choose. This is 
>>> how everything else in the world that integrates SLF4J has to operate so I 
>>> don't really see us being any different.
>>>
>>> I'll wait until tomorrow to re-spin.
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to