On 11.10.2012 12:17, Anders Hammar wrote:
A plugin declaring a dependency on slf4j-api without declaring a
dependency on an implementation does not makes sense imo. It follows
that the term "declaring a dependency on slf4j" means a dependency on
both slf4j-api as well as a binding, aka implementation.
If the get the slf4j logger injected they would only have a slf4j-api
dependency, wouldn't they? I'm asking as I *think* we said we would
use slf4j as the logging interface in Maven.
Yes, the maven-core dependency is on slf4j-api, not any particular impl.
Only classes from the org.slf4j package are imported.
What I'm thinking is that the aim is to allow plugins to use the core
slf4j logging, right? But we would like to keep any existing behavior
where a plugin logs to it's own logging file through slf4j, right?
So then we can't check on a slf4j-api dependency, but need to look for an impl.
If a plugin declares a dependency on say slf4j-jdk14, and assuming dep
declarations in plugins are transitive, than plugin's classloader will
also have classes from slf4j-api.jar in addition to those from
slf4j-jdk14.jar. Thus, when the plugin imports
org.slf4j.LoggerFactory, the instance of LoggerFactory will be bound
to JUL.
I think it makes sense to study actual plugins declaring a dependency
on slf4j, instead of imagining problems which may or may not exist.
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
