[
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
