On traction we can agree to disagree. Logback may be more popular but we are pretty busy answering user's questions, and making enhancements and fixes. I follow the Logback lists and actually see less activity there. And I continue to see users ask frameworks to support Log4j 2. Frankly, I was surprised when I found my current employer adopted Log4j 2 before I started working there. And the architectural reasons for Log4j 2 coming about still have not been addressed by Logback.
I agree with the option proposed. Ralph > On Jan 8, 2016, at 5:38 AM, Jason van Zyl <[email protected]> wrote: > > Ralph, > > The simple fact of the matter is that Log4J2 appears to have little to no > user traction at all. This suggests to me that the community forked into the > next generation by way of Logback and Log4J2. The community appears to have > gone in the direction of Logback. By a very large margin, at least for the > time being. I just don’t see it as a valuable or practical choice to use > Log4J2, maybe you don’t see Logback as a valuable or practical choice. That > said I think what Tamas suggested is fair. We’ll get the extensions to work > in some form and then it’s convenient for users to choose by configuration > what they prefer. And it appears we’ll have three choices. I think it’s fine > they are built in the core to ensure they work, but not distributed but > deployed to Maven Central for optional use. I am perfectly fine with that. > > Reasonable? > >> On Jan 7, 2016, at 1:47 PM, Ralph Goers <[email protected]> wrote: >> >> He claims that Log4j 2 isn’t popular enough. The real reason, as you >> probably know, is that Jason seriously dislikes me, although he would never >> actually say that as his reason. >> >> Ralph >> >>> On Jan 7, 2016, at 10:56 AM, Jason van Zyl <[email protected]> wrote: >>> >>> >>>> On Jan 7, 2016, at 11:43 AM, Arnaud Héritier <[email protected]> wrote: >>>> >>>> No problem. >>>> Let's do what you want (like always). >>> >>> Not that I want it, but that’s certainly never been the case. The project >>> would most definitely look different if it were. If there is agreement on >>> this I’ll be surprised. So... >>> >>> If we can make it such that the .mvn/extensions.xml mechanism work for >>> logging that would be best but it won’t right now because Igor discovered >>> in his journeys that SLF4J can only be initialized once. And by the time >>> the extensions load it’s too late. If we can either adjust the CLI such >>> that we delay the initialization until after extensions load and live with >>> some STDOUT hackery, or ask the SLF4J folks if they can accommodate our >>> case and have some lazy initialization or allowable mutation. Then it just >>> doesn’t matter and anyone can cleanly use what they wish. Then we’ll likely >>> have to figure out global user extensions but that’s ok. >>> >>>> I agree we are loosing our time. >>>> >>>> Have a good day. >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Takari and Apache Maven >>> http://twitter.com/jvanzyl >>> http://twitter.com/takari_io >>> --------------------------------------------------------- >>> >>> You are never dedicated to something you have complete confidence in. >>> No one is fanatically shouting that the sun is going to rise tomorrow. >>> They know it is going to rise tomorrow. When people are fanatically >>> dedicated to political or religious faiths or any other kind of >>> dogmas or goals, it's always because these dogmas or >>> goals are in doubt. >>> >>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>> >>> >>> --------------------------------------------------------------------- >>> 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] > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Takari and Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > {script:nopre:"/Users/jvanzyl/signature/signature.sh"} > > > --------------------------------------------------------------------- > 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]
