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. 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...) 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] > >
