On Dec 11, 2012, at 5:07 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> 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? Umm.. how about adding things, like color? > 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. I completely agree with this. The -X behavior sucks and if logback can provide something better, that's great. However, if log4j can ALSO provide something that is equivalent to what logback could provide, then I would go with log4j. Basically, if given 2 essentially equivalent choices, I'd go with the community supported, permissively licensed option. That does require, however, 2 essentially equivalent choices. From what I see for our specific CLI use case, the two options are very close. Dan > > > 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
