2012/12/17 Stephen Connolly <[email protected]>: > On 17 December 2012 15:07, Mark Struberg <[email protected]> wrote: > >> Sorry Stephen, I find this comparison unfair. >> > > > Mark, here is my point. > > To move forward on the logging over slf4j plan (A plan you are against, and > I have not seen any one else support your cause) we need to pick an > implementation. > > Initially JvZ's idea was to avoid picking an implementation (I personally > suspect because he thought there would be war... but I will leave JvZ to > confirm or deny my suspicions). That basically means picking slf4j-simple. > > Things looked good with slf4j-simple... until some issues in the > integration tests popped up... JvZ reports that he tried to hobble > slf4j-simple to the finish line and that he got some patchwork bit of an > impl to crawl over the finish line (but with an unacceptable performance > regression) > > Then he tried with logback. JvZ is reporting (unconfirmed) that he has > logback passing all integration tests > (ed4b5bf98f520d0c9775e5bb6fb7075ac1db5fa0) and on that same branch I and > IIRC a number of others have not found any performance regressions on those > sample builds we have tried with. > > JvZ started a vote to use logback on that basis. > > I corrected the vote to say that we needed to pick an implementation, gave > some criteria that should be included. Pointed out that the licensing > requirements should be secondary to the technical requirements. In other > words *if* there are technical reasons why the best implementation is Cat B > *then* we should choose the best implementation. [Note: I have not seen > anyone give technical reasons to favour any implementation over any > other... I may have missed them] > > I knocked together four branches to allow people to compare apples with > apples, as Olivier's log4j2 branch was a bit old and therefore likely did > not contain the necessary fixes for the slf4j issues. I also compiled > branches for JUL and log4j 1.2 > > I found no major performance issues between the 4 branches and 3.0.4. I > think I reported this, but I may have forgotten. > > Technical issues exist with 2 of the four branches we currently have: > > 1. JUL does not support MDC (which is required to deliver improvements in > the amount of information logged) > 2. log4j 1.2 needs a proper appender that does not suffer the threading > issues known with the standard appenders in log4j 1.2 and needs to tweak > the output so that we have [WARNING] and not [WARN] > > Now the above could be fixed... but *somebody* needs to write some code to > make them fixed. In the absence of anyone writing such code and committing > it, those branches are dead... as are those choices. > > IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO > GET THEM WALKING AGAIN > > That leaves logback and log4j2 on the table... > > JvZ has said that logback passes the ITs > I have asked quite pointedly that Olivier (or anyone who is advocating for > log4j2) would run the ITs and provide confirmation that log4j2 passes the > ITs. branch logging/slf4j-log4j2 pass it (at least locally) and with this jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/ > > I would expect the "other" side in either choice, or an independent third > party (such as Mr Jenkins if he can be made to get the integration tests to > pass at all) to provide confirmation that their "opposition" either has a > branch that passes the integration tests or a claim that they are needing > to give better proof. > > Now into that maelstrom Benson struck with his $0.02... arguing against > log4j2 (for now) which kind of leaves us with logback (unless one of the > other branches is brought back from the dead by somebody writing some > code...) My 0.02 euros. Perso I use log4j2 for months without any issue. And performance are good. Even here with Maven ! (See various reports from folks on the other thread) I read http://logging.apache.org/log4j/2.x/performance.html (agree benchmarks depends on various factors (and could be maybe different if runed somewhere else) but that's something to take care. Then Log4j2 is a community developpement effort and have a good license for our Maven.
> > Then Olivier decided to propose a 6th way (since we have had so far: > slf4j-simple; logback; log4j 2.0; log4j 1.2; JUL) namely a plexus-logging > backed implementation of slf4j-api... > > It was to that 6th option that I said he needs to write some code if he > wants that to be considered. Such an implementation needs to support MDC > and needs to pass all the integration tests. > > > >> Please look how much code has been written and is necessary to get slf4j >> (and any other non MojoLogger impl) really running. > > > The light of a thousand suns that is -X needs to be tamed. MDC (or > equivalent) is required to tame that beast. JUL is not going to give us > MDC, so slf4j-api is the only route that I can see to go towards MDC. > > What we are talking about is the code to be written to integrate a specific > implementation into the CLI (or in Olivier's 6th way, that also includes > the actual (to be written) slf4j-plexus-logging implementation > > >> And for making it fully work it will need even more work because we first >> need to ship all plugins with an upgraded maven-plugin-plugin build. >> > > I smell FUD again. My understanding is Hervé is working on the solution to > that. > > >> >> >> And most of the log output in projects (surefire) will still funneled via >> a stdio redirecting, so all the benefit is lost for them, isn't? >> > > Have you run with -X recently? > > >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >> > From: Stephen Connolly <[email protected]> >> > To: Maven Developers List <[email protected]> >> > Cc: >> > Sent: Monday, December 17, 2012 3:58 PM >> > Subject: Re: Logging >> > >> > On 17 December 2012 14:46, Olivier Lamy <[email protected]> wrote: >> > >> >> And what about working on real improvements for users ? >> >> >> >> I see: >> >> * incremental build >> >> * fixing various bugs on dependency plugin (tree doesn't work well >> >> since aether: http://jira.codehaus.org/browse/MDEP-392) or this very >> >> old one (https://jira.codehaus.org/browse/MDEP-187) which have 50 >> >> votes. And IMHO dependency:tree is one of the most important when you >> >> want to debug to dependencies. >> >> * some jiras we have for core. link >> >> ( >> >> >> > >> https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel >> >> ) >> >> says 648 open issues ! And they are some very blockers/majors here. >> >> * etc... >> >> >> >> Regarding logging, move to slf4j and by default add our own slf4j >> >> implementation based on the current plexus logging (then we can simply >> >> provide a plugin for users who want to choose an other impl, this >> >> plugin will simply update users installations). >> >> >> > >> > That sounds like somebody has to write some code... I don't want to write >> > some code to handle logging, so I say go for the implementation that >> > involves not writing code and be done with it. Of the two left on the >> table >> > by Benson only one is ready without writing more code... unless somebody >> > against that option wants to step up and write the code that is ;-) >> > >> > >> >> Integrators can simply made their own packaging as they do today. >> >> >> >> >> >> >> >> >> >> >> >> 2012/12/16 Benson Margulies <[email protected]>: >> >> > Since not much has been heard on the 'pick a logger' question >> > for some >> >> > time, I'm going to stick my neck out and try to summarize some >> >> > aspects, in the hopes of discovering how close we are to a consensus. >> >> > >> >> > In the following, I use the word 'want' to express >> > *preference*, not >> >> > non-negotiable demands. >> >> > >> >> > We all need: reasonable performance, an acceptable license (i.e. >> >> > category A or B), a stable, reliable, logger. >> >> > >> >> > Various of us want: MDCs, colorization: a package with a community >> >> > behind it, an avoidance of of EPL, to use our fellow >> > Apache-projects' >> >> > outputs. >> >> > >> >> > We know that: java.util.logging isn't going to give us MDCs or >> >> > colorization without a great deal of effort. So I'm crossing it >> > off in >> >> > this email. >> >> > >> >> > Now, I'm going to express an opinion based on all the email >> > *I've* >> >> > seen. I don't claim to be right, but I wonder if people would be >> >> > willing to follow my logic. >> >> > >> >> > Once we eliminate j.u.l from consideration, our choices are logback, >> >> > log4j 1.x, and log4j 2.x. >> >> > >> >> > It seems to me that log4j 2.x is not really ready for us yet, so in >> >> > this email I'm crossing it off. If we continue to dither for >> > another >> >> > few months, that might change. If someone disagrees, I'm sure >> > they'll >> >> > respond. >> >> > >> >> > log4j1.x is the tried and true alternative. Colorization, however, >> >> > would require significant effort. Those of us who don't give a fig >> >> > about colourization won't be perturbed by this. >> >> > >> >> > logback, on the other hand, is very widely adopted, and no one seems >> >> > to be able to offer any *technical* objection to it. And it gives us >> >> > colorization out of the box. >> >> > >> >> > The objections to logback, then, are cultural, organizational, and/or >> >> > related to license. >> >> > >> >> > In my view, the very broad adoption of logback seems to me to >> >> > neutralize the concern that it's a one-man-band. While one person >> >> > projects present certain risks in the abstract, this particular one >> >> > seems to me not to raise them. >> >> > >> >> > In my view, objecting based on EPL is, as I wrote once before, not >> >> > appropriate. The Maven project erected a barrier to EPL dependencies >> >> > to respond to cases in which core Maven functionality was forked and >> >> > EPL-ified, or just proposed to be replaced by EPL code. The situation >> >> > with logging is simply not analogous. As a project, I don't think >> > we >> >> > need to anticipate wanting to bring the logging system into our >> >> > source. Adding a category B logging dependency does not contribute to >> >> > the 'hollowing out' of Maven. >> >> > >> >> > As a Foundation, category B licenses are just as acceptable as >> >> > category A licenses as dependencies. (I also wonder why this barrier >> >> > was not specifically set up in terms of 'core code replaced by >> > non-A' >> >> > instead of 'EPL'). >> >> > >> >> > If I add this all up, to me it amounts to a test. If some member(s) >> of >> >> > this community really, really, want to take log4j 1.x in order to >> > 'use >> >> > Apache' or 'have a community', I think that those people >> > should be >> >> > willing to step up and *write the code* to make log4j 1.x >> >> > feature-equivalent with logback for our purposes. The same logic >> would >> >> > apply to j.u.l, though my impression is that there is no practical >> >> > coding path that gets to equivalence. >> >> > >> >> > I trust that this email will inspire response; perhaps it will >> inspire >> >> > a response that allows us to detect some consensus. >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> > >> >> >> >> >> >> >> >> -- >> >> Olivier Lamy >> >> Talend: http://coders.talend.com >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
