Thanks a lot to have pushed it. I tested it with success I like it, at least something that will improve the user experience soon. Note : Like Olivier's branch the default logging setup has an issue because the default color is set to black (or white) which are backgrounds colors commonly used. This is something we'll have to take care. The best should be to not touch the default foreground color for INFO level and just add colors for others levels.
Cheers, On Sat, Dec 1, 2012 at 6:47 PM, Jason van Zyl <ja...@tesla.io> wrote: > I already have started a logback version, but I don't think this should > affect rolling the 3.1.0. > > On Dec 1, 2012, at 6:57 AM, Arnaud Héritier <aherit...@gmail.com> wrote: > > > I pushed the prototype developed by olivier using log4j2 in the > > branch feature/colorized-console/log4j2 > > I updated with latest master changes > > You can test the distro of this code : http://cl.ly/1B1z051O0T10 > > > > Tonight I'll try to do a logback version > > > > cheers > > > > Arnaud > > > > > > On Sat, Dec 1, 2012 at 11:15 AM, Arnaud Héritier <aherit...@gmail.com > >wrote: > > > >> > >> > >> > >> On Sat, Dec 1, 2012 at 9:40 AM, Hervé BOUTEMY <herve.bout...@free.fr > >wrote: > >> > >>> I just created and fixed MNG-5395 and MNG-5396, which are logger names > >>> enhancements from the actual values that will give value even with > slf4j- > >>> simple > >>> > >>> These should be a starting point for more global discussion about our > >>> logging > >>> conventions then fixed in our global codebase, since IMHO, these issues > >>> show > >>> how we didn't use the logger names until now then we have a lot of > place > >>> where > >>> our logging pratice is not good > >>> > >>> Of course, I'm interested in colorized output, but since it has impact > on > >>> logging implementation choice, which will require a strong discussion, > >>> this > >>> can't be done for the moment :| > >>> > >> > >> > >> A strong discussion ? seriously ? > >> We have 3 choices from my point of view : > >> * We do nothing, we keep the slf4j-simple > >> * We choose logback which is mature and used by a lot of people. > Nowadays > >> from my point of view it is the reference implementation > >> * We choose log4j2 which is really promising but always in beta. But we > >> may do this "political" to support this project which is rising from the > >> ashes (http://logging.apache.org/log4j/2.x/manual/index.html) > >> > >> In any case doing a choice nowadays for 3.1.0 won't prevent us to change > >> it in the future. I really hope that the ability to switch from a logger > >> implementation to another won't require several days of developments or > I > >> really missed something about it. > >> > >> Cheers > >> > >> > >> Arnaud > >> > >> > >> > >>> > >>> Regards, > >>> > >>> Hervé > >>> > >>> Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit : > >>>> Hi Jason, > >>>> > >>>> Couldn't we have a look at olamy's log4j2 branch to see if we could > >>>> sanitize / merge it to propose at least one change for the end user > >>>> and demonstrate the interest of the change about logs : a colorized > >>>> console. > >>>> > >>>> I remember you did that in mvnsh/teslashell a long time ago (as an > >>>> extension ?) and perhaps it could be easy to add properly this feature > >>>> in 3.1.0 (otherwise it won't be before a 3.2.0). > >>>> > >>>> Myself I'm using a 3.1.0 fork with this patch and I' m really > >>>> satisfied (it's so good to quickly see highlighted warning and errors > >>>> ). I merged it back in the last 3.1.0 tag you did without issue > >>>> > >>>> Wdyt? > >>>> > >>>> --------- > >>>> Arnaud > >>>> > >>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit : > >>>>> I'm done with the issues that cropped up so I'm ready to re-spin > >>> 3.1.0. > >>>>> > >>>>> Anyone want to add anything or discuss anything before I spin this? > >>> I'm > >>>>> not in any rush so if folks want to talk about logging we can. But > >>> given > >>>>> the fact once SLF4J initializes it can't change the implementation > >>>>> plugins integrating with Maven need to use the implementation we > >>> choose. > >>>>> This is how everything else in the world that integrates SLF4J has to > >>>>> operate so I don't really see us being any different. > >>>>> > >>>>> I'll wait until tomorrow to re-spin. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Jason > >>>>> > >>>>> ---------------------------------------------------------- > >>>>> Jason van Zyl > >>>>> Founder & CTO, Sonatype > >>>>> Founder, Apache Maven > >>>>> http://twitter.com/jvanzyl > >>>>> --------------------------------------------------------- > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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 > >>> > >>> > >> > >> > >> -- > >> ----- > >> Arnaud Héritier > >> http://aheritier.net > >> Mail/GTalk: aheritier AT gmail DOT com > >> Twitter/Skype : aheritier > >> > >> > > > > > > -- > > ----- > > Arnaud Héritier > > http://aheritier.net > > Mail/GTalk: aheritier AT gmail DOT com > > Twitter/Skype : aheritier > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > > > > > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
