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 <[email protected]> wrote: > http://markmail.org/message/mpgn4yshnt2qmdui > > 2012/12/10 Jason van Zyl <[email protected]>: >> 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 <[email protected]> wrote: >> >>> 2012/12/10 Hervé BOUTEMY <[email protected]>: >>>> 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 <[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:;> >>>>> >>>>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> --------------------------------------------------------------------- >>> 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 >> --------------------------------------------------------- >> >> We know what we are, but know not what we may be. >> >> -- Shakespeare >> >> >> >> >> > > --------------------------------------------------------------------- > 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 --------------------------------------------------------- To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
