Hi Rusty,
Letting the end user choose the underlying logging framework is the
reason SLF4J exists in the first place. If you specify the actual
binding in the pom file of your library, users can no longer choose the
logging library which negates SLF4J's purpose.
The instructions on dependencies should be part of the SLF4J docs so
that authors of libraries can reference them. Such instructions are
currently missing. Perhaps that was the point of your post...
Cheers,
On 12/08/2011 1:14 AM, Rusty Wright wrote:
Suppose I'm developing a library that will be used in another person's
project and my library uses slf4j. And I don't know what logging
framework they use. Should my distribution include slf4j-log412.jar and
slf4j-jdk14.jar (or, better, specify both of them as a dependency in my
maven pom.xml)? Or should I include instructions that they'll need to
download and use either of those jars, depending on which logging
framework they're using?
Here's what's in my pom.xml at the moment (for logging); the test scope
is what keeps the underlying logging framework I'm using (logback) from
being a runtime/compile dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${version.slf4j}</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<!-- use provided scope on real JCL. -->
<!-- ensures it's not inadvertently pulled in, -->
<!-- so that we can use jcl-over-slf4j. -->
<version>1.1.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging-api</artifactId>
<!-- use provided scope on real JCL. -->
<!-- ensures it's not inadvertently pulled in, -->
<!-- so that we can use jcl-over-slf4j. -->
<version>1.1</version>
<scope>provided</scope>
</dependency>
<!-- the slf4j commons-logging replacement -->
<!-- if any package is using jakarta commons logging this will -->
<!-- re-route it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${version.slf4j}</version>
<scope>test</scope>
</dependency>
<!-- the slf4j log4j replacement. -->
<!-- if any package is using log4j this will re-route -->
<!-- it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>${version.slf4j}</version>
<scope>test</scope>
</dependency>
<!-- the slf4j java.util.logging replacement. -->
<!-- if any package is using java.util.logging this will re-route -->
<!-- it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>${version.slf4j}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${version.logback}</version>
<scope>test</scope>
</dependency>
On 2011-08-11 13:36, Ceki Gülcü wrote:
Hi again,
Here is another more comprehensive attempt. It's hard for me to say
how much of an improvement these are.
Comments welcome.
--
Ceki
--
QOS.ch, main sponsor of cal10n, logback and slf4j open source projects,
is looking to hire talented software developers. For further details,
see http://logback.qos.ch/job.html
_______________________________________________
slf4j-user mailing list
slf4j-user@qos.ch
http://qos.ch/mailman/listinfo/slf4j-user
