[displaytag-devel] [jira] Commented: (DISPL-646) POM config exposes unneeded dependencies to client apps
[ http://jira.codehaus.org/browse/DISPL-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204816#action_204816 ] Michael Osipov commented on DISPL-646: -- 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 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
[displaytag-devel] [jira] Commented: (DISPL-646) POM config exposes unneeded dependencies to client apps
[ http://jira.codehaus.org/browse/DISPL-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204537#action_204537 ] Michael Osipov commented on DISPL-646: -- 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. 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
[displaytag-devel] [jira] Commented: (DISPL-646) POM config exposes unneeded dependencies to client apps
[ http://jira.codehaus.org/browse/DISPL-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[displaytag-devel] [jira] Commented: (DISPL-646) POM config exposes unneeded dependencies to client apps
[ http://jira.codehaus.org/browse/DISPL-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20#action_20 ] Michael Osipov commented on DISPL-646: -- 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. 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
[displaytag-devel] [jira] Commented: (DISPL-646) POM config exposes unneeded dependencies to client apps
[ http://jira.codehaus.org/browse/DISPL-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
