Hi,
Besides agreeding with Curt's concerns, this seems unnecessary. Why do it?
Introducing yet another set of names, interfaces, classes is unlikely to be
well-received...
Yoav
--- Curt Arnold <carnold@apache.org> wrote:
> This is in regards to recently filed bug 36805 (http://
> issues.apache.org/bugzilla/show_bug.cgi?id=36805). If there has been
> any previous discussion, I have missed it.
>
> All this information may be in attachments to the bug, but it would
> be helpful to me if you provide some essential background information.
>
> What is the source of the initial submission? Do you have clear
> rights to donate the code to Apache Software Foundation? Do you have
> a Contributor's License Agreement (http://www.apache.org/licenses) on
> file?
>
> Do you think that the code would need to go through the Incubator
> (http://incubator.apache.org)
>
> How does this relate to GNU Classpath (http://www.gnu.org/software/
> classpath/) which provides independent clean-room implementations of
> core class libraries and appears to implement java.util.logging? The
> GNU Classpath implementations take great care avoid potential legal
> issues (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)
> that we don't encounter.
>
> How would conflicts between the JDK provided implementation of
> java.util.logging and JULI be resolved?
>
> SLF4J is not an Apache project and having an Apache product depend on
> a non-ASF project is undesirable. What is the nature of the
> dependency on SLF4J?
>
> Is JULI an acronym? If so, what is the full name?
>
> My initial reaction is that there are too many legal and licensing
> issues to justify the project in light of only vague outlined benefits.
>
>
>
|