http://bugzilla.slf4j.org/show_bug.cgi?id=31
------- Comment #22 from [EMAIL PROTECTED] 2008-04-24 17:23 ------- I have read and re-read this report to ensure that I was not succumbing to NIH syndrome. I think my position stated in comment #10, dated 2007-10-10 21:27:12, is still relevant. Quoting: I think providing multiple versions of the API is too complicated as well as error prone. Logging has to be simple. As soon as one tries to be smart about logging, things start to crumble. (Simplicity and robustness is SLF4J's main selling point.) I appreciate your effort. [snip] Your solution produces two jars which need to be documented and installed separately. Most importantly, our user base has to be educated about it. Given the number of SLF4J users, that's too much of a hassle. After careful review of your proposal, although it has real merit, I am sorry to reject it. As for the second proposal which changes the artifact id to slf4j-api-jdk15, the problem of educating our users remains an issue. Moreover, it is not hard to imagine cases where both slf4j-api and slf4j-api-jdk15 would be present simultaneously in a project. For example, let us assume that project P depends on D1 and D1. D1 depends on slf4j-api and D2 on slf4j-api-jdk15, causing a conflict. Admittedly, this conflict could be avoided by excluding the slfj-api dependency. But what would happen if the a J2EE container exported SLF4J? For instance, the Geronimo project just switched to SLF4J. What if Geronimo exported slf4j-api while some application was expecting slf4j-api-jdk15? -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
