[slf4j-dev] svn commit: r769 - slf4j/trunk/slf4j-site/src/site/resources

[ceki at slf4j.org]

Author: ceki
Date: Mon Feb 26 08:27:06 2007
New Revision: 769

Modified:
   slf4j/trunk/slf4j-site/src/site/resources/faq.html
   slf4j/trunk/slf4j-site/src/site/resources/index.html
   slf4j/trunk/slf4j-site/src/site/resources/news.html

Log:
minor doc enhancements

Modified: slf4j/trunk/slf4j-site/src/site/resources/faq.html
==============================================================================
--- slf4j/trunk/slf4j-site/src/site/resources/faq.html	(original)
+++ slf4j/trunk/slf4j-site/src/site/resources/faq.html	Mon Feb 26 08:27:06 2007
@@ -275,7 +275,7 @@
         <em>slf4j-simple.jar</em>, <em>slf4j-log4j12.jar</em>, and
         <em>slf4j-jdk14.jar</em>. These files ship with the <a
         href="download.html">official SLF4J distribution</a>. Please
-        note that all binding depend on <em>slf4j-api.jar</em>.
+        note that all bindings depend on <em>slf4j-api.jar</em>.
        </p>
         
         <p>The binding for logback-classic ships with the <a

Modified: slf4j/trunk/slf4j-site/src/site/resources/index.html
==============================================================================
--- slf4j/trunk/slf4j-site/src/site/resources/index.html	(original)
+++ slf4j/trunk/slf4j-site/src/site/resources/index.html	Mon Feb 26 08:27:06 2007
@@ -52,13 +52,13 @@
   <p>SLF4J does not rely on any special class loader machinery. In
   fact, the binding between SLF4J and a given logging API
   implementation is performed <em>statically</em> at compile time of
-  each binding. Each binding is hardwired to use one and only one specific
-  logging API implementation. Each binding corresponds to one jar
-  file. In your code, you simply drop the binding of your choice, that
-  is a jar file, onto the appropriate class path location. As a
-  consequence of this simple approach, SLF4J suffers from none of the
-  class loader problems or memory leaks observed with Jakarta Commons
-  Logging (JCL).
+  each binding. Each binding is hardwired to use one and only one
+  specific logging API implementation. Each binding corresponds to one
+  jar file. In your code, in addition to <em>slf4j-api.jar</em>, you
+  simply drop the binding of your choice, that is a jar file, onto the
+  appropriate class path location. As a consequence of this simple
+  approach, SLF4J suffers from none of the class loader problems or
+  memory leaks observed with Jakarta Commons Logging (JCL).
   </p>
 
   <p>We hope that simplicity of the SLF4J interfaces and the deployment
@@ -68,8 +68,8 @@
 
   <h3>Projects depending on SLF4j</h3>
 
-  <p>Here is a short list of projects currently depending on SLF4J (in
-  alphabetical order):
+  <p>Here is a non-exhaustive list of projects currently depending on
+  SLF4J, in alphabetical order:
   </p>
 
   <ul>

Modified: slf4j/trunk/slf4j-site/src/site/resources/news.html
==============================================================================
--- slf4j/trunk/slf4j-site/src/site/resources/news.html	(original)
+++ slf4j/trunk/slf4j-site/src/site/resources/news.html	Mon Feb 26 08:27:06 2007
@@ -22,8 +22,9 @@
 
   <h1>SLF4J News</h1>
 
-  <p>You can receive SLF4J related announcements by subscribing to the
-  <a href="http://www.slf4j.org/mailman/listinfo/announce">SLF4J
+  <p>Please note that you can receive SLF4J related announcements by
+  subscribing to the <a
+  href="http://www.slf4j.org/mailman/listinfo/announce">SLF4J
   announce</a> mailing list.
   </p>
 
@@ -35,16 +36,19 @@
   projects. More specifically, the
   <code>org.slf4j.LoggerFactory</code> class is now packaged within
   the <em>slf4j-api.jar</em> file instead of the various slf4j
-  bindings. It follows that client code needs to depend on only
+  bindings. <b>It follows that client code needs to depend on only
   slf4j-api in order to compile, while the various slf4j bindings are
-  only needed as runtime dependencies. See also the <a
-  href="faq.html#maven2">Maven2-related FAQ entry</a>.
+  only needed as runtime dependencies.</b> See also the <a
+  href="faq.html#maven2">Maven2-related FAQ entry</a>. Given the
+  practical significance of this change, we highly recommend that
+  library-authors upgrade to version 1.3 at their earliest
+  convenience.
   </p>
   
-  <p><a href="http://bugzilla.slf4j.org/show_bug.cgi?id=23">Bug
-  number 23</a> has been fixed, at the cost of minor and backward
-  compatible changes. In other words, jcl104-over-slf4j now
-  preserves caller location information.
+  <p><a href="http://bugzilla.slf4j.org/show_bug.cgi?id=23">Bug number
+  23</a> has been fixed, at the cost of minor and backward compatible
+  changes. In other words, jcl104-over-slf4j now preserves caller
+  location information.
   </p>
   
   <p>It is now possible to obtain the root logger of the underlying