I cannot content is here https://svn.apache.org/repos/infra/websites/production/maven/content/ just need to be checkout a first time. As some asked to have documentation for plugins for each version we have a lot of content. So need some time, so tea time for me.
2012/12/10 Jason van Zyl <ja...@tesla.io>: > Maybe you can copy over the index.html we can prevent the directory listing > from showing up on our home page. > > On Dec 10, 2012, at 10:03 AM, Olivier Lamy <ol...@apache.org> wrote: > >> http://markmail.org/message/mpgn4yshnt2qmdui >> >> 2012/12/10 Jason van Zyl <ja...@tesla.io>: >>> Not sure what's happening but: >>> >>> http://maven.apache.org/developers/dependency-policies.html >>> >>> is not there. >>> >>> On Dec 10, 2012, at 3:25 AM, Olivier Lamy <ol...@apache.org> wrote: >>> >>>> 2012/12/10 Hervé BOUTEMY <herve.bout...@free.fr>: >>>>> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit : >>>>>> 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, >>>>> logging *implementation*, please, not framework: the framework is >>>>> slf4j-api, >>>>> on which our code will have much dependency. The logging implementation >>>>> is far >>>>> less invasive choice (even if not completely null). >>>>> >>>>>> but I don't think there is anyone against using Logback. >>>>> why this provocation? (should I say lack of respect for others opinion?) >>>>> >>>>>> I honestly don't think >>>>>> there is any rational argument for not using Logback, 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. >>>>> we'll need to wait for 3.1.1 and a vote to have a chance to stop tension >>>>> about >>>>> this: whatever choice is done, there will be some devs unhappy who will >>>>> have >>>>> to live with it >>>>> >>>>> notice I won't be able to reply for the next half day, my intent with this >>>>> reply is just to avoid one more re-spin of a feeling that the vote won't >>>>> happen and let Olivier once more jump on the case >>>>> I just hope I won't have to read a lot of replies to this tonight when I'm >>>>> back from work and loose my time carefully reading if anything new or >>>>> interesting is written >>>>> >>>> >>>> I have already explained my opinion. >>>> Folks think log4j2 is "immature" and/or don't have a community of >>>> various people. >>>> >>>> Furthermore it looks it's not anymore possible to use "immature" >>>> libraries in core (whereas it has been done for more important part: >>>> sisu or aether). >>>> >>>> But now that's not anymore possible... >>>> Well things evolve and POV can change that's the life.... >>>> >>>> BTW due to our policy [1] and if I correctly read license here [2] a >>>> vote is mandatory. (and don't ask me to start this vote :-) ). >>>> >>>> Cheers >>>> -- >>>> Olivier >>>> [1] http://maven.apache.org/developers/dependency-policies >>>> [2] http://logback.qos.ch/license.html >>>> >>>>> Regards, >>>>> >>>>> Hervé >>>>> >>>>>> 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:;> >>>>>> >>>>>> 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 >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Olivier Lamy >>>> Talend: http://coders.talend.com >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder & CTO, Sonatype >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> We know what we are, but know not what we may be. >>> >>> -- Shakespeare >>> >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > To do two things at once is to do neither. > > -- Publilius Syrus, Roman slave, first century B.C. > > > > > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
