On Dec 10, 2012, at 3:46 PM, John Casey <[email protected]> wrote:
> On 12/10/12 2:42 PM, Jason van Zyl wrote: >> It would be the default backend, people would not be using Logback APIs >> directly. >> >> The one place where it's convenient for use the use the Logback APIs is in >> the CLI where it's not possible to change the log levels without talking >> directly to the implementation. > > IMO the CLI isn't usable from an embedding standpoint anyway, so it almost > doesn't count (it's almost part of the distribution .zip). > Yup, I was just pointing out that we do have to reach into its pocket to do some things. >> >> On Dec 10, 2012, at 3:40 PM, John Casey <[email protected]> wrote: >> >>> Reading through the rest of the thread...is this for the default >>> implementation we'll ship with maven, or are we talking about skipping the >>> slf4j-api abstraction and using logback apis directly? >>> >>> If it's just the default backend, I'm not concerned at all. If we're >>> forcing people to use logback, then to me that's a lot less attractive. >>> >>> On 12/10/12 2:34 PM, John Casey wrote: >>>> 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 <[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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> 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 >> --------------------------------------------------------- >> >> Selfish deeds are the shortest path to self destruction. >> >> -- The Seven Samuari, Akira Kurosawa >> >> >> >> >> >> > > > -- > 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] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
