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] http://en.wikipedia.org/wiki/Eclipse_Public_License (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
Logback.
On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <[email protected]> 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 http://maven.apache.org/developers/dependency-policies ?).
What do we need (for 3.1.0) ? What do we do ?
Arnaud
On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <[email protected]> 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 <
[email protected]> wrote:
On Sunday, 9 December 2012, Kristian Rosenvold wrote:
2012/12/9 Olivier Lamy <[email protected] <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 any
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: [email protected]<javascript:;>
For additional commands, e-mail: [email protected]
<javascript:;>
--
-----
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
---------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Benjamin Franklin
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
