On Dec 1, 2012, at 2:24 PM, Mark Struberg <[email protected]> wrote:
> >> How many times does someone really need a different implementation? > > Sorry Jason, thats bollocks and you know it. > You looked at the the question and presumed an answer. You're assuming my is never. The answer is not very often, which begs the question of balance between creating a convoluted mechanism for accommodating the infrequency of that requirement versus having something simpler, less magic, smaller and working for most cases. > > >> 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. It's not broken, it has side effects as all things do. > Thanks for finally acknowledging this. So why the hell do we force a single > established framework to any user at all? As that's generally what most do in order to avoid having to support all combinations of things which is untenable. > That's the reason why any sane container I know doesn't do that. > I see most containers picking defaults. > > 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. > Then implement it Mark and demonstrate, you keep talking about this but the whole while haven't demonstrated any of your theory. Olivier and I may be disagreeing but we're both doing work and making implementations. As I said before I am not in a terrible rush so implement what you think works best and show us. > 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] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- We know what we are, but know not what we may be. -- Shakespeare
