[
https://issues.apache.org/jira/browse/MAHOUT-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852965#action_12852965
]
Benson Margulies edited comment on MAHOUT-361 at 4/2/10 9:51 PM:
-----------------------------------------------------------------
Keep in mind that I got unhappy about this because some really not-very-loggy
classes in collections now touch the slf4j API and demand a working config.
I see two plausible alternatives.
Alternative #1: remove the test scope. This requires non-JCL users to put some
relatively fiddly stuff in their POM, but it avoids requiring everyone to pick
one and add it. And the result works out-of-the-box. And for some people, jcl
is good enough in terms of logging flexibility.
Alternative #2: rethink this.
2a: use java.util logging. Anyone who wants another backend can use the SLF4J
technology.
2b: Borrow from CXF. CXF wanted to (a) support I18N and (b) avoid the situation
we are in right now. So, they wrote their own simple logging wrapper. By
default, it goes to j.u.l, but by putting a file in classpath you tell it to
use some other logger.
In short, they built a mini-SLF4J with two big differences: I18N and a working
default configuration. Since that code is sitting in a nearby Apache project,
we can pretty easily expropriate it.
was (Author: bmargulies):
Keep in mind that I got unhappy about this because some really
not-very-loggy classes in collections now touch the slf4j API and demand a
working config.
I see two plausible alternatives.
Alternative #1: remove the test scope. This requires non-JCL users to put some
relatively fiddly stuff in their POM, but it avoids requiring everyone to pick
one and add it. And the result works out-of-the-box. And for some people, jcl
is good enough in terms of logging flexibility.
Alternative #2: rethink this.
2a: use java.util logging. Anyone who wants another backend can use the SLF4J
technology.
2b: Borrow from CXF. CXF wanted to (a) support I18N and (b) about the situation
we are in right now. So, they wrote their own simple logging wrapper. By
default, it goes to j.u.l, but by putting a file in classpath you tell it to
use some other logger.
In short, they built a mini-SLF4J with two big differences: I18N and a working
default configuration. Since that code is sitting in a nearby Apache project,
we can pretty easily expropriate it.
> SLF4J dependency structure leads to unpleasant surproses
> --------------------------------------------------------
>
> Key: MAHOUT-361
> URL: https://issues.apache.org/jira/browse/MAHOUT-361
> Project: Mahout
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 0.3
> Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> Our poms declare a dependency on the slf4j core, but not on any of the
> implementation modules. Thus, if an unsuspecting user adds a dependency on
> our stuff, and runs, they get a exception from slf4j complaining that there's
> no implementation. I claim that it would be more better to declare a
> dependency on the JDK14 module, and those users who really care about using
> something else can exclude it and include their own.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
