POM config exposes unneeded dependencies to client apps

Michael Osipov added a comment - 29/Dec/09 3:14 PM Hopefully you have noticed that DisplayTag uses JCL natively and thus it requires jcl over sfl4j and its transitive deps. Turing DisplayTag to slf4j native would require code changes. Using jcl over slf4j requires none and makes use of slf4j by default.

Jeff Jensen added a comment - 29/Dec/09 9:27 PM 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.

Michael Osipov added a comment - 30/Dec/09 4:28 AM Jeff, I must admit, yes the POM is misconfigured. slf4j-log4j binding is absolutely useless. But I still do disagree, slf4j itself is not unnecessary. It completely replaces JCL because it's old, not performant as SFL4J and most people moved to SFL4J anyway. At least in my projects I use SFL4J exclusively. I excluded the false transitive deps.

Jeff Jensen added a comment - 30/Dec/09 8:42 AM 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. ;-)

Michael Osipov added a comment - 01/Jan/10 8:48 AM DisplayTag would work without SFL4J, that's correct but you would need JCL anyway. What's the point. The bridge binding has been chosen as a mild migration path to native SLF4J logging. I mailed Fabrizio since I want to have the project leadership. I use this lib almost daily at work and patched some stuff already. Hopefully I will be able to fix those nasty bugs like this one. Mike