I want to gently argue with a part of Dan Kulp's position. The PMC established the class B dependency rule in response to a particular conflict within this community. From my point of view, whether or not that conflict is entirely in our past, logback is not an example of the problem that the rule was intended to address. It is not a case of forking Maven code out and then licensing the derived work as EPL.
If we ever got that far, I would argue pretty strenuously against a PMC-level rejection of something just based on being EPL. A class-B license is a perfectly legitimate dependency. Dan's points about preferring to use something with a community behind it do not disturb me. However, seriously, does anyone believe that any of these candidates are going to manifest some horrible problem that we need to get fixed? To me, the sophistication depends on our vision for the widespread use of the slf4j API in plugins. I hate the current -X behavior, with its horrible undifferentiated spew, with the power of 1000 suns. If picking logback offers a clean engineering pathway to helping users see only messages that will help them (which, of course, depends on plugins enabling the slf4j API and using it), then I'm all for logback. If there's all much of a muchness in this regard, then we might as well use the JDK. On Tue, Dec 11, 2012 at 4:54 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > On 11 December 2012 21:49, Olivier Lamy <ol...@apache.org> wrote: > >> 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 ? >> > > All integration tests pass and no significant performance regression (I > would say >5% is significant but I agree we do not have a strict measure of > that). > > My first mail on this thread is awaiting confirmation from you that log4j2 > meets the above. > > >> >> > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
