On Sep 9, 2012 8:08:34 pm, Ralh Goers wrote: > First, I also would recommend moving from plexus logging to SLF4J.
Cool. > Mark's concerns with incompatibilities only come about with the log4j > bridge if you are trying to use APis that the SLF4J bridge hasn't > implemented. Something being used in a plugin really shouldn't be > using those. Exactly. > Although Ceki is generally careful not to break compatibility, it has > happened. For example, you cannot mix applications that use SLF4J > 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much > tied to the SLF4J version. See http://www.slf4j.org/news.html. If > core is using SLF4J and an incompatible change is made again it > probably won't be that big of a deal. Typically, when compatibility > has been broken it really hasn't impacted code that uses the SLF4J > API. SLF4J's user facing API, that is classes or interfaces located in the org.slf4j package such as Logger, Marker, MDC and LoggerFactory have been there and remain unchanged since day one (2005). Thus, a user never has to worry about with which version of slf4j-api a dependency was compiled with. A user can pick any version of slf4j-api-api.jar and as long as the version of the binding of her choice matches, slf4j will function correctly. See also [1,2]. The internal interfaces, those in the org.slf4j.spi or org.slf4j.helpers packages, may change incompatibly. One of the most notable occasions was in the 1.6.0 release when the LocationAwareLogger interface was changed. It was done so in response to a bug report [3] filed by... Ralph. The reader will appreciate the irony. More objectively though, Ralph filed a valid bug report and the only way to fix it was by making an incompatible change in an *internal* interface. Unfortunately, given the ubiquity of SLF4J, such incompatible changes somehow manage to leak into user-space and annoy the hell out of many developers. SLF4J is designed so that the problems occurring when deploying SLF4J are obvious with obvious solutions -- SLF4J is stupid by design. (Feel free to quote.) > Mark mentioned shading as a way to "fix" any problems with SLF4J > conflicts. I am not sure if shading will work with SLF4J. > Implementations must provide a class named > org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder > and org.slf4j.impl.StaticMDCBinder. > > Jason made a comment in a previous reply that said "Ceki is also a > committer, and will help us fix anything when necessary so that, > again, we can focus on Maven and not logging." > http://people.apache.org/committer-index.html doesn't list him as a > committer on Maven and Ceki has said publicly and privately that he is > unlikely to contribute to ASF projects. However, while the statement > is incorrect I don't understand why what Ceki would or wouldn't do > would have any bearing on whether Maven adopts SLF4J. If need be, I'll happily answer questions and guide you through the process of migrating to SLF4J. However, I agree with Ralph, my person should have no bearing to whether Maven adopts SLF4J or not. > Finally, I've been working on Log4j 2 for over 3 years now. The reason > I started working on it was due to deficiencies in Logback that occur > in large scale web applications and probably don't matter in something > like Maven. But it would be nice to allow the end user the ability to > swap out the logging implementation if they want. Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. In my not so humble opinion, all other questions are moot if you don't have a working policy for swapping-in/swapping-out logging frameworks. Lacking the necessary knowledge about how Maven bootstraps itself or how it manages its classloaders, I am not in a position to formulate such policy. On the other hand, there is more than enough expert knowledge here to address this problem. I intend to follow your future discussions with interest. [1] http://www.slf4j.org/manual.html#compatibility [2] http://www.slf4j.org/codes.html#version_mismatch [3] http://bugzilla.slf4j.org/show_bug.cgi?id=127 -- Ceki http://tinyurl.com/proLogback --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
