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. On Dec 10, 2012, at 3:40 PM, John Casey <jdca...@commonjava.org> 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 <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 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
