>Hi,
>Obviously there are already enough -1's ;) Let's pull the release off the
>server, as I don't think the current disclaimer is sufficient.
>
>And let's start a separate thread to discuss dependence on slf4j. I wonder if
>it can be done dynamically, with runtime discovery or a similar mechanism,
>rather than as a hard compile-time dependency.
I think Ceki's idea of having hard compile-time dependencies is the only solution I know of that avoids the commons-logging nightmare. Any other proposed solution would have to be at least as robust. In any case, this is different than the issue of whether Log4j-1.2.x or Log4j-1.3.x should implement the interfaces or use a facade, which is mostly what has been discussed over the past couple days. In any case, I think Mark started a new thread, so any further comments should go there.
Jake
>
>Yoav
>
>Quoting Scott Deboy <[EMAIL PROTECTED]>:
>
>> As a formality, I'm proposing a vote on releasing log4j 1.2.10.
>>
>> As previously mentioned, I am -1 on the release at this point pending further
>> discussion.
>>
>> Scott
>>
>>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
