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 <[EMAIL PROTECTED]> 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. > > >
