personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path...
Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey <jdca...@commonjava.org> wrote: > > > On 6/10/11 3:48 AM, Mark Struberg wrote: >> >> We partly use slf4j internally already for tests, etc. >> But moving the whole Logger mess over to slf4j would be really great. >> There are lots of tests (I sadly also found productive code too) still using >> System.out.println. >> >> The question is if we (internally) drop org.codehaus.plexus.logging.Logger >> completely and use slf4j directly, or if we pimp up the plexus Logger and >> add various stuff. > > I've been thinking about this for some time now, actually. If you look at > the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. > > Personally, I don't understand what value the Plexus logger/loggermanager > has, especially given the configurability of these other logging frameworks. > > I'd be in favor of providing a "default" logging configuration file in > either the Maven app directory or in ~/.m2, and then letting people > customize from the command line to highlight specific components/packages. > > Although, having said that, one of my pet peeves about the logging > frameworks is they haven't shifted to using String.format, > MessageFormat.format, or whatever under-the-covers as a way of limiting > string concatenation in cases where a particular log level has been > disabled. > > Even something as simple as the attached code would be a nice facade for > logging, IMO...but it's more of a wish-list item than anything else. > > In short, yes, let's think about switching to a better logging framework. We > can deprecate the plexus logger, and eventually get rid of it! > >> >> We would need to do some compat code anyway, but I'm not sure if it pays >> off to restrict ourself. At least not after I saw that even the >> LoggerManager uses System.err.println: >> >> // TODO: use a logger! >> System.err.println( "There was no such logger '" + key + "' " + hashCode() >> + "." ); >> >> dumdidum :) >> >> LieGrue, >> strub >> >> >> --- On Fri, 6/10/11, Ralph Goers<ralph.go...@dslextreme.com> wrote: >> >>> From: Ralph Goers<ralph.go...@dslextreme.com> >>> Subject: Re: Get thee to the Core... >>> To: "Maven Developers List"<dev@maven.apache.org> >>> Date: Friday, June 10, 2011, 5:03 AM >>> >>> On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: >>> >>>> I'd like to offer a small suggestion. >>>> >>>> One of the big barriers to maven happiness is the >>> >>> difficulty of >>>> >>>> understanding, in some cases, why it does what it >>> >>> does. >>>> >>>> This suggests to me three efforts that might offer an >>> >>> opportunity to >>>> >>>> learn core code without drowning. >>>> >>>> 1: take up slf4j, and thus allow component (indeed >>> >>> class) by component >>>> >>>> log control as an alternative to the giant -X spew. >>> >>> Now that is an interesting idea. For the past year I have >>> been working on creating Log4j 2.0 pretty much by >>> myself. This would be a great way to integrate it into >>> something useful. >>> >>> Ralph >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > -- > John Casey > Developer, PMC Member - Apache Maven (http://maven.apache.org) > Blog: http://www.johnofalltrades.name/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
