However, if you are using SLF4J as the facade and Logback purely as an implementation it's best practice to declare SLF4J as a compile time dependency and Logback as a runtime one - that will save you from accidentally depending on a Logback specific class.
Even if you need to compile against Logback it's best practice to specify any other libraries (such as SLF4J) you need on the compile time classpath explicitly rather than relying on transitive dependencies - it's kind of a mistake in Maven that transitive compile scope dependencies are brought in as compile scope, they should really only be runtime scope. On 25 Oct 2011, at 11:41, ceki <[email protected]> wrote: > > FYI, given Maven's transitive dependency rules, writing: > > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-classic</artifactId> > <version>0.9.30</version> > </dependency> > > is equivalent to writing: > > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-api</artifactId> > <version>1.6.3</version> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-core</artifactId> > <version>0.9.30</version> > </dependency> > <dependency> > <groupId>ch.qos.logback</groupId> > <artifactId>logback-classic</artifactId> > <version>0.9.30</version> > </dependency> > > > _______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
