Would be easy enough to create a template method in MavenCli which in which subclasses can override to do any setup of the underlying logging system. Much like the createModelProcessor() method in the MavenCli currently.
On Dec 11, 2012, at 7:39 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > same for me > > with one precision: IMHO, the few places where we'll have to write > implementation-specific code need to be placed in a separate class to ease > changing implementation > > Regards, > > Hervé > > Le mardi 11 décembre 2012 16:19:12 Daniel Kulp a écrit : >> My thoughts: >> 99.5% (or more) of the maven users will not care one way or another what >> logging impl we use. They won't configure anything beyond -X. They won't >> try changing loggers. They won't muck with the configs. Etc.. They >> just run "mvn" and expect it to work. >> >> For the remaining <0.5%, no matter what we do, we will need to document >> things clearly about how to configure things. For these folks, they are >> generally "experts" and thus a couple extra steps to replace a logging >> framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT >> this all clearly or provide a nice maven plugin or something to do it for >> them) >> >> >> My preference, in order: >> >> slf4j-jdk14 >> slf4j-simple >> log4j2 >> slf4j-log4j >> >> and then a big gap to logback. >> >> The first two are there as they would provide the least amount of "extra >> dependencies", complexity, etc… That said, we know slf4j-simple has >> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI >> case, I don't see any advantage of logback over log4j2 or slf4j-log4j. >> If the entire argument is around wanting something "battle tested", go for >> slf4j-log4j. It's certainly used by more projects than logback and more >> people would already know it's configuration options. Personally, I find >> the "number of projects" argument annoying and mostly irrelevant. (and at >> least 2 of the "Apache 8" projects that are on the logback homepage don't >> use logback, they now use slf4j-log4j) >> >> Thus, it comes down to two major things for me: >> >> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to vote >> -1 for logback if/when presented to the PMC for approval. There are very >> good options that would work just as well for our needs that are not EPL. >> >> 2) Community - Ceki is great, no doubt about it, but at the end of the day, >> logback is pretty much a one man show. Apache is more about "community" >> and "community over code" and all that. I strongly prefer something that >> has a community behind it, or, at the very least, is open to developing a >> community behind it. Major bonus points if that community already >> contains Maven PMC members/committers on it. If *we* run into issues, I >> strongly prefer that *we* can get those issues fixed. >> >> If two options are functionally and technically equivalent (within >> reasonable limits), then I'll take the community driven, permissive >> licensed version. >> >> That's my $0.02 worth. >> >> Dan >> >> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <ja...@tesla.io> wrote: >>> Hi, >>> >>> I looked around a bit more today and I don't think SLF4J Simple is viable >>> long term, I don't want to patch it anymore as I would have to do a day's >>> work to make changes that keep the performance levels up, get it reviewed >>> and released, and I honestly don't think it's worth it anymore. I would >>> rather spend my time building out the plugin test cases and help to >>> finish the classloader blocking of SLF4J. I don't mind spending time >>> getting it all working but I don't want to waste my time on an >>> implementation we're going to toss. >>> >>> After a conversation with the PMC it will require a vote to accept Logback >>> which is EPL but I wanted to ask committers and interested users about >>> using Logback. I believe Logback is the best choice as it's the most >>> mature and battle tested implementation because once it goes in it's >>> likely not ever to come out. Many of us are users and have integration >>> experience with Logback and it's what I use everyday for logging in all >>> my other projects and I've been a happy user for years. I see Logback as >>> best of breed and widely adopted including 8 projects at Apache. >>> >>> There's no point in asking the PMC to vote on the acceptance of Logback if >>> it's not acceptable by the community. If there are interested users I >>> would really like to hear what you think because you're the ones who will >>> have to live with the choice that is made. >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder & CTO, Sonatype >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> To do two things at once is to do neither. >>> >>> -- Publilius Syrus, Roman slave, first century B.C. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > 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
