On 12/10/12 2:25 PM, Jason van Zyl wrote:
John,
Eight other projects at Apache use Logback.
The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems
with the EPL. I don't think JBoss would ship a huge product entirely based on
EPL if there were a problem.
Oracle also now accepts EPL dependencies in their products.
So what, exactly, is the potential problem?
I'm not on the drools team, I was only trying to help them use the Maven
/ Aether APIs. Conan mentioned the EPL-ness of Aether as a potential
problem for them, and was hoping to use Maven to avoid it until I told
him that Maven itself is using Aether. His answer was that they would
work around it by isolating the functionality into a separate module
with different licensing (or something, I didn't get into the details
with him). Either he's not clear on the license interactions, or there
is an actual problem that will propagate these licensing complexities
out to any GPL project embedding Maven. IANAL.
I'm only relating a conversation that was specifically dealing with this
issue.
Increasingly, my work is with integrating Maven into other tools as
well. Personally, I'd prefer something that keeps the licensing clean.
AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses.
I'm not sure how we deal with this internally, but it's a conversation
that comes up periodically. I don't claim to know all the ins and outs,
and I think it's not reasonable for someone outside the projects /
products themselves to claim they do.
I think it comes down to: Are the licenses compatible? If not, are we
forcing people to make a decision about taking on extra licensing
complexity in order to embed Maven?
On Dec 10, 2012, at 3:14 PM, John Casey <jdca...@commonjava.org> wrote:
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 <aherit...@gmail.com> 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 <and...@hammar.net> 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 <
stephen.alan.conno...@gmail.com> wrote:
On Sunday, 9 December 2012, Kristian Rosenvold wrote:
2012/12/9 Olivier Lamy <ol...@apache.org <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: dev-unsubscr...@maven.apache.org<javascript:;>
For additional commands, e-mail: dev-h...@maven.apache.org
<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
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
