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'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]
