maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject Re: Logging
Date Mon, 10 Dec 2012 20:14:32 GMT
On 12/9/12 7:50 PM, Jason van Zyl wrote:
> I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding
problem, but we're likely to run into issues concurrency with parallel builds and who knows
what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work
but I think we're pushing the simple implementation beyond its scope. So I'd just like to
put in Logback and be done with it.
> There are at least three of us opposed to using a new logging framework, but I don't
think there is anyone against using Logback. I honestly don't think there is any rational
argument for not using Logback,

I guess m2e and related third-party projects are the things requiring 
these "more evolved" logging options.

One rational argument against including logback is other third-party 
projects that wish to embed Maven but which have licensing conflicts 
with EPL. I had a conversation just the other day with the drools folks 
over this WRT Aether, where its EPL license was a potential problem for 
them. [1]

In considering third-party integration, doesn't it make sense to try to 
stay clear of introducing licensing problems? Isn't that rational?

[1] (see the sidebar)

so after doing all the SLF4J work and making a best effort to use SLF4J 
Simple I think it's pointless to pursue that path any longer and put in 
> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <> wrote:
>> I'm a little bit lost too.
>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for
>> many - good - reasons) but the last bug discovered by Kristian can be
>> solved only
>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>> - to be validated by Ceki)
>> * or by using a more evolved impl like logback (or log4j ...).
>> I think that everyone's will prefer the first solution if possible but if
>> we cannot we'll have the question to select the impl.
>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>> Like I said in another thread I'll understand if the project decide to
>> choose log4j2 even if it is young because we want to support another ASF
>> initiative (And I'm sure we won't have to regret it, and we'll have a
>> really good support from its team) but in a general case I would prefer to
>> choose logback which is today the reference logging framework (I that case
>> we need to have a PMC vote to accept an external component under EPL
>> license ?).
>> What do we need (for 3.1.0) ? What do we do ?
>> Arnaud
>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <> wrote:
>>> Not sure where to get into this thread, but I'd just like to add my
>>> perspective on this topic.
>>> For this first release I would prefer it to not include any of the more
>>> advanced slf4j implementations, like a few others have already also stated.
>>> Using simple would give us a good start on this new path while we
>>> investigate what we and the community want feature wise and then select an
>>> implementation based on these requirements. However, if slf4-simple can't
>>> do the job of the old behavior when we might not have that option
>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>> leave that to others working with that to decide.
>>> But if we have to decide on a more advanced implementation my choice would
>>> be logback. My choice is based on two things where one being a past
>>> experience where I developed an audit logging solution based on logback,
>>> where my research showed that log4j had so many deficiencies when it came
>>> to more advanced cases. log4j2 might be a different story with this fixed
>>> though, but I don't see any reason trying something else when there is
>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>> help us out should we need that. I'm not saying those working with log4j2
>>> will not, it's just that I don't know their track record as I know Ceki's.
>>> But to repeat myself, going simple in the first release would be so much
>>> better. Then we could get our requirements after this first release and do
>>> a selection based on them rather than just a gut feeling. Although using
>>> slf4j as the API gives us the technical possibility of switching impl later
>>> on, I don't think we want that as we can probably expect some people do
>>> solutions expecting a specific impl (as we've seen in the Sonar plugin for
>>> example).
>>> /Anders
>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>> wrote:
>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>> 2012/12/9 Olivier Lamy < <javascript:;>>:
>>>>>> Perso I'm fine using log4j2.
>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>> Furthermore I'm fine working with an Apache community in case of
>>>>>> issue we could have.
>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>> going,  but I'm firmly opposed
>>>>> to including a brand new logging framework as default in m3.
>>>> +1
>>>>> Kristian
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:<javascript:;>
>>>>> For additional commands, e-mail:
>>> <javascript:;>
>> --
>> -----
>> Arnaud Héritier
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
> Thanks,
> Jason
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> ---------------------------------------------------------
> Three people can keep a secret provided two of them are dead.
>   -- Benjamin Franklin

John Casey
Developer, PMC Member - Apache Maven (
GitHub -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message