> On Jan 8, 2016, at 3:21 PM, Dennis Lundberg <[email protected]> wrote:
> 
> Hi,
> 
> The sometimes heated discussion in this thread shows that there are strong
> opinions about logging implementation. That for me is a reason to not
> bundle one by default.
> 
> Let us focus on making it as simple as possible for our end users to
> configure which one they want to use.
> 

That’s not more simple, say versus bundling an implementation, but it will 
relieve us from the cherished biannual discussion about logging frameworks. 

> I'm not familiar with the extension mechanism. What alternatives do we have
> to configure this? Ideally without the user having to download and
> installing anything manually - only configuration in some xml file
> somewhere.

This is how it works. You state the coordinate of the extension you wish to use 
and its downloaded an integrated automatically.

The issue Igor ran into is that in the MavenCli we initialize SLF4J before the 
extensions are loaded and the way we are currently doing it the loggers are 
fully bound which precludes the extension from working. I had a discussion with 
Ceki and he gave me two ways to try a temporary binding, followed by a 
permanent binding which on paper seems to match our use case. The other 
alternative is making sure that we figure out, by whatever means, the 
implementation we intend to use for logging be it the one in the distribution 
or in an extensions and only initialize once. I think either way is doable and 
Ceki has agreed to review the code. If Igor will let me I’ll try the suggested 
techniques with his code.

> Den 8 jan 2016 13:38 skrev "Jason van Zyl" <[email protected]>:
> 
>> 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]
>> 
>> 

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]

Reply via email to