On Sat, Dec 1, 2012 at 4:44 PM, Olivier Lamy <[email protected]> wrote: > 2012/12/1 Jason van Zyl <[email protected]>: >> >> On Dec 1, 2012, at 12:39 PM, Olivier Lamy <[email protected]> wrote: >> >>> Hi, >>> >>> Why do we have to force our users to a specific logging implementation >>> than we choose ? >> >> My counter argument is why don't we? That is the pattern of most forms of >> integration because trying to account for many implementations interacting >> together have unknown side affects. Just because you can do something >> doesn't mean it's useful. >> >>> 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 :-) ) >> >> The point again is just because you can do doesn't mean it's useful. How >> many times does someone really need a different implementation? Just because >> someone wants something doesn't mean you should give it to them. I believe >> just allowing anything isn't actually helpful to anyone. >> >>> >>> 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" >>> >> >> I don't think that's particularly easy and additionally opens us up to >> having to specifically support any SLF4J implementation which I don't think >> is wise. >> > if documented that's not really complicated. > > this could be nice for ci servers to get logs easily. > We already have eventspy to intercept build informations so why not > having something else for logs. > > >> I think we need to pick one and go with it. If users want something >> different they can change the structure of the distribution. >> >>> 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 think that 'Maven, the command-line tool' should have one(*) logging back end. I think that 'Maven, the embeddable build system' should have, as an advantage, the ability to log to any slf4j backend that the embedding application cares to use. In between is a gray area, where a 'power user' might read documentation that explains how to reconfigure the usual command-line directory tree to use a different back end, via Olivier's mechanism. Doing so would come with a disclaimer. But I don't see how it has to be a gigantic disclaimer. If it works for embedding to pick any slf4j back end, then it's hard for me to see gigantic risks to a user in reconfiguring the command-line package. I am fine with rolling 3.1.0(-?) as-is, and then pull in Olivier's work and reviewing it, or pulling it in first, FWIW. >>>>>> >>>>>> 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] >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder & CTO, Sonatype >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> What matters is not ideas, but the people who have them. Good people can fix >> bad ideas, but good ideas can't save bad people. >> >> -- Paul Graham >> >> >> >> >> > > That's not because we disagree that you are right. > -- Winston Churchill > > --------------------------------------------------------------------- > 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]
