On 17 December 2012 14:46, Olivier Lamy <ol...@apache.org> 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 <bimargul...@gmail.com>: > > 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: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
