+10000000000 i really think "maven is bad" sentences we sometimes hear doesn't reference the logging at all so probably not something where time should be lost
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2012/12/17 Olivier Lamy <ol...@apache.org>: > 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). > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
