My understanding is that whichever choice is made, there will need to be some support code in CLI to allow for CLI options for tweaking the logging level (i.e. -X to turn on DEBUG). As I do not yet know what that code will look like I cannot say if a straight remove selected impl and drop in alternative impl will work fully.
I would expect that you could replace the impl and then you would have to configure that impl to control its logging. So my hope would be that, assuming for the sake of an example log4j2 is chosen, you remove log4j2.jar from the Maven CLI lib folder and add in logback.jar. At that point Maven CLI should not blow up but -X does not affect the logging output and a new "--quiet" option will not turn off INFO level. But through the use of system properties or dropping in a logging configuration file into Maven's classpath you can control logging in that regard. I do not think developers want to support the logger implementation specific code for multiple implementations as it just multiplies out our testing requirements. Note: I have my own opinion on which logging framework we should choose. I am trying very carefully not to expose that preference in this thread (though it should be trivial for anyone to find my opinion by searching the recent archives) in order to allow this thread to be free from any perceived bias from myself. I will provide details of my vote when there is a significant engagement from the community. Do not take anything in the above as an endorsement on my behalf of any option for the logging framework. -Stephen On 11 December 2012 19:55, Dan Tran <dant...@gmail.com> wrote: > +1 on for logback. > > However, is it possible to switch to Log4j2 by manually repackage > maven distribution? > > Thanks > > -D > > On Tue, Dec 11, 2012 at 10:57 AM, Anders Hammar <and...@hammar.net> wrote: > > I'm +1 for logback as the slf4j impl. > > > > /Anders > > > > > > On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl <ja...@tesla.io> 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. > >> > >> > >> > >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
