[ http://jira.codehaus.org/browse/DISPL-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204561#action_204561 ]
Jeff Jensen commented on DISPL-646: ----------------------------------- Agreed, I use SLF4J as much as I can, which is nearly always (as with my current customer where I discovered this problem!). I nearly always use Logback as well for the logging implementation. JCL, JUL, Log4J are inferior. I also agree that for your situation, SLF4J completely replaces JCL. But as you said, displaytag is written to JCL, not SLF4J. So displaytag *would work* without any SLF4J deps, correct? I am not disagreeing with your choice of using SLF4J, I am disagreeing with your choice to force it and specific versions on client code when they do not need to be! :-) This forces users to unnecessarily add exclusions to fix the SFL4J binding error, eliminate unnecesary deps (most notably in web-inf/lib such as different versions or the log4j one), and have potential SLF4J dep version problems. As a best practice, it is up to the user of the framework to choose those things (e.g. use jcl over slf4j or not) that are not directly used. So I think I understand that, since JCL is "...old, not performant as SFL4J...", you've decided to "convert" in a very easy way to SLF4J by adding slf4j-api and jcl104-over-slf4j. That definitely works, but I think that should be my choice when the product uses JCL directly. While my sfl4j over jcl version is 1.5.10 and need to exclude displaytag's ones, it would be a nice correction to fix the log4j binding, either removing it or changing to test. In the meantime, of course, it works to exclude it as well. ;-) > POM config exposes unneeded dependencies to client apps > ------------------------------------------------------- > > Key: DISPL-646 > URL: http://jira.codehaus.org/browse/DISPL-646 > Project: DisplayTag > Issue Type: Bug > Components: Build/distribution > Affects Versions: 1.2 > Reporter: Jeff Jensen > > DisplayTag transitive dependencies cause erroneous configuration on client > projects. Specifically, DisplayTag should depend on only slf4j-api in the > compile scope, resulting in exposing only that required dependency to client > apps, and the slf4j-log4j12 and jcl104-over-slf4j dependencies should be > removed (or changed to test scope if wanted for local testing). > slf4j-api would be a new direct dependency to DisplayTag. It currently is > transitively brought in through the slf4j-log4j12 direct dependency. > I noticed this because, after just adding DisplayTag to my web app, SLF4J > gave error messages on multiple SLF4J bindings on app startup - one binding > is correctly from my POM/app config (found in logback-classic) and the other > is erroneously exposed transitively from DisplayTag's dependency > slf4j-log4j12. > See http://www.slf4j.org/codes.html#multiple_bindings for the SLF4J error. > The root cause is the DisplayTag POM exposing slf4j-log4j12 and > jcl104-over-slf4j dependencies. Client apps do not need those specifically, > e.g. slf4j-log4j12 is not needed with Logback. > This dependency configuration approach also forces client apps to have log4j > on the classpath transitively from slf4j-log4j12. We do not use Log4J. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ displaytag-devel mailing list displaytag-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/displaytag-devel