2012/12/11 Stephen Connolly <stephen.alan.conno...@gmail.com>: > On Tuesday, 11 December 2012, Daniel Kulp wrote: > >> >> >> 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. > > > My points are: > > 1. that we should make sure the selected implementation passes the > technical gate *first* >
Any technical definition of this gate ? > 2. That committers should not worry about the outcome of a PMC vote when > making their recommendation on implementation. If the PMC chooses to say no > to a specific dependency on the basis of its license *then* the community > will presumably have a second option that passes the technical gate and can > fall back to that... But the very first question that committers should > consider is the technical basis. > > I don't care what criteria people use as long as technical is #1. > > >> >> 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. > I have already explained my opinion in other threads. So nothing more to add (maybe I'm lazy for copy/paste :-)) I tend to follow Dan explanations as it's similar to mine. So -1 for logback. > > Thank you for stating your criteria > > I wish everyone else could follow your example > > >> >> That's my $0.02 worth. >> >> Dan >> >> >> >> >> >> >> >> >> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <ja...@tesla.io <javascript:;>> >> 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. >> > >> > >> > >> > >> > >> >> -- >> Daniel Kulp >> dk...@apache.org <javascript:;> - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> >> For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
