Le mardi 11 décembre 2012 20:27:15 Jason van Zyl a écrit : > 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. yes IMHO, this could give an idea of what new API would be useful in slf4j-api in future versions: I don't expect much methods
Regards, Hervé > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
