On Tue, Dec 11, 2012 at 5:32 PM, Daniel Kulp <dk...@apache.org> wrote: > > 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?
I don't know about that. I'll think about it. > >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
