when we branch we can look at logging frameworks and versions then, sl4j
seems like a good choice.
Mark
Geoffrey De Smet wrote:
I've just switched solver to use slf4j:
http://jira.jboss.com/jira/browse/JBRULES-1233
I am advising to configure drools-repository and drools-jbrms's
logging dependency's like this:
<!-- Logging -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<scope>test</scope>
</dependency>
They both need a directy dependency on slf4j-api, because you should
only really on transitive dependencies if the only reason you need a
transitive dependency is because one of your direct dependencies needs
it.
Since Logger is used directly, a direct dependency on slf4j-api should
be put at scope compile.
I don't think drools-repository/jbrms want to force their users to use
log4j. But unless slf4j-log4j12 is put at test scope (or another scope
with optional true) that is the case. Currently it's like this: we use
a logging facade so you can log with anything, but we force you to use
log4j anyway (luckily users could have excluded it meanwhile as a
workaround).
Maybe the log4j dependency is obsolete (as slf4j-log4j12 brings it
in), but he solver examples use a domconfigurer directly, so at least
solver needs it :/
PS: could we upgrade to the latest slf4j libs?
We're at 1.3.0 and the latest is 1.4.3
http://www.mvnrepository.com/artifact/org.slf4j/slf4j-api
For solver it shouldn't give a problem, maybe for drools-repository it
will?
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
