[
http://jira.codehaus.org/browse/DISPL-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204513#action_204513
]
Jeff Jensen commented on DISPL-646:
-----------------------------------
Thanks for the response. If all displaytag uses is JCL, then the slf4j and
related deps are not necessary and should be removed. It is up to the user to
declare if they want slf4j or other logging libs (some user may even want
JCL!). Currently, displaytag is forcing those deps and specific versions on
client apps. It also causes an slf4j binding error.
Not only is it declaring slf4j and the JCL converter, but a log4j one as well.
My guess is the log4j one is there so your tests have a log implementation for
the messages? If that is correct, that is why I suggested changing any such as
the log4j dep to test scope.
The purpose of JCL or SLF4j is to allow users to choose the implementing
logging framework. The purpose of dependencies is to declare which ones are
required to use the product/framework. The only required logging deps for
displaytag, based on your note, is JCL. If there are uses of some SLF4j in
displaytag, then the only other required dep is slf4j-api. The other deps are
for users to choose to use or not - which framework(s) they want to handle the
messages.
Hopefully this is clearer why this is a displaytag POM configuration error -
exposing unneeded (possibly conflicting) deps and causing a slf4j binding error.
> 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
