> How many times does someone really need a different implementation? Sorry Jason, thats bollocks and you know it.
> That is the pattern of most forms of > integration because trying to account for many implementations interacting > together have unknown side affects. You are wrong and right at the same time: Yes it's broken and has unknown side effects. Thanks for finally acknowledging this. So why the hell do we force a single established framework to any user at all? That's the reason why any sane container I know doesn't do that. Again: the easy solution would be a slf4j-MojoLogging bridge and all is fine. Plugins which like to use slf4j can simply use this bridge and all is fine. Other plugins will not be hurt. LieGrue, strub ----- Original Message ----- > From: Jason van Zyl <[email protected]> > To: Maven Developers List <[email protected]> > Cc: > Sent: Saturday, December 1, 2012 10:31 PM > Subject: Re: Re-spinning 3.1.0 > > > 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. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
