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? On Dec 10, 2012, at 3:14 PM, John Casey <[email protected]> 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 <[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 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
