A the end of the day we could have both actually! Most plugins will add both as dependency. Otherwise they would not be able to log via slf4j.
But there are also libraries like OpenJPA (via openjpa-maven-plugin) which do auto detection. They look up what impls are available and decide what to use. In OpenJPA you can even force the one you like to use via a property in persistence.xml. So in the real world it's even more complicated. I'm not sure how to translate "Das Leben ist kein Kindergeburtstag" - literally it would be "live is no children birthday" ;) LieGrue, strub ----- Original Message ----- > From: Anders Hammar <and...@hammar.net> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Thursday, October 11, 2012 10:24 AM > Subject: Re: SLF4J integration > > Just to get this clear in my head: > When you're talking about "slf4j dependency" in a plugin, are you > talking about dependency to slf4j-api or an slf4j impl? > > /Anders > > On Thu, Oct 11, 2012 at 10:16 AM, ceki <c...@qos.ch> wrote: >> On 11.10.2012 08:37, Mark Struberg wrote: >> >> Hi Mark, >> >>> Hi Ceki, thanks for the reply! >> >> >>>> The method signatures of classes in the org.slf4j package such as? >>>> Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.? >>> >>> No they are not. I did a diff between 1.2 and the latest and it >>> seems a few trace() methods got added. This is only a minor problem >>> but still. This change is perfectly backward compatible, but it's > not >>> forward compatible. If there is any new signature added/changed in a >>> newer version which we will not yet use, then we would just crash if a >>> plugin uses the newer version. Now this is highly unlikely. But > I've >>> seen this with commons logging and I've seen this with the >>> LocationAwareLoger as you already mentioned below. This is btw exactly >>> the reason why we shade in all commons-* stuff to private packages... >> >> Correct. The trace method was added in SLF4J version 1.4 released on >> May 16th 2007. Interestingly enough, I can't remember a single >> complaint about missing trace method. About 1% of slf4j-users use >> versions earlier than 1.4. Among that 1%, even fewer have a dependency >> requiring the trace method. As an end result, and as far as I can >> tell, no one complains about the missing trace method in earlier slf4j >> versions. >> >> My point is that there are some imaginary problems that never occur in >> practice. In practice, the slf4j version some software is compiled >> with is never a problem assuming it only imports from the org.slf4j >> package. >> >>>> this means that the minor version of the SLF4J binding >>>> must match that of the slf4j-api. The "maintenance" >>>> number is unimportant. >>> >> >>> That's perfectly fine that way! Please understand that this is >>> nothing against slf4j! I just like to avoid that we introduce build >>> problems to existing projects. As highlighted in my previous post >>> there ARE ways to do that (by shielding via ClassWorlds), but this is >>> not in place in trunk yet. Also there are zero integration tests for >>> it atm! >> >> OK. >> >>> Maven uses a child-first classloading strategy (with exceptions) - a >>> plugin would only see exactly 1 version. Currently (again: there is >>> atm no shielding in place yet) if a plugin would would provide it's >>> own slf4j-api-1.4.2 then the plugin would get this version of the >>> Class. And if the plugin would invoke >>> LoggerFactory.getLogger(this.class()) then what would happen? Most >>> probably a classcast exception, right? There is a minor chance that we >>> do not blow up as there is a complex ClassLoading environment in >>> place. But we only know after we have some IT in place which do not >>> exist yet. All the change got committed without a single IT, thus my >>> -1 in the first place. >> >> >> While I agree with the gist of your argument, I still maintain that >> "slf4j versions" is not the crux of the matter here. However, as > you >> point out, class isolation should be implemented and tested. >> >>> >>>>> 2.) if you use slf4j, then ALL the funnels and logging backends > must >>>>> have the very same version number than the slf4j-api. Otherwise > you >>>>> are pretty much doomed. Ceki, is this correct as well? >>>> >>>> >>>> I would not go as far as "doomed". For example, the > following >>>> combination will work fine: slf4j-api-1.7.2.jar, >>>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar, >>>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other > words, >>>> you can freely mix artifacts in the 1.6.x and 1.7.x families. >> >> >>> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No >>> you cannot as far as I've seen. So we cannot make a general > assumption >>> on that! The only safe rule is to not mix slf4j parts with diverging >>> major or minor number. Is this correct? >> >> Yes, that is correct. >> >> >>> >>>> Sounds good. I would recommend isolation regardless of the version > of >>>> the discovered slf4j dependency. The plugin author probably wishes >>>> logging isolation. Maven should let the plugin have its own > separate >>>> logging environment distinct from Maven's own logging. >> >> >>> But that would actually be a big step backwards imo. >> >> No, separating maven logging and plugin logging (for the plugins that >> explicitly set their own slf4j logging environment) is not a step >> backwards. On the contrary, it preserves existing behavior. >> >> In my earlier message, I apparently did not insist enough on the the >> point that isolation was only required for the minority of plugins >> which set up their own slf4j-based logging environment. The vast >> majority of plugins which do not declare an slf4j dependency, would >> get their slf4j loggers either via injection or via getLogger(). >> >>> Currently any plugin is forced to 'funnel' the output into the >>> logger it obtains via getLogger() itself. This is an instance of >>> org.apache.maven.plugin.logging.Log and we have it perfectly under our >>> own control. It's not a perfectly convenient logging api but it > works >>> and shields us from all implementation details! >> >> This has been discussed earlier so I won't respond. >> >>> If we would isolate away all the logging of a plugin (because it >>> contains a diverging slf4j version) then we would loose all this logs, >>> right? >> >> Of course not. The logs would be available in the logging environment >> proper to the plugin (declaring its own logging environment), that's >> the beauty of this approach. >> >>> It is perfectly valid for any plugin to use slf4j right now. >> >> >> Absolutely. >> >>> All it needs to do is to funnel it into our own maven logging >>> api. We could e.g. provide a slf4j-maven-logging backend so users >>> could use it even more easily. >> >> >> I think that's an understandable mistake but a mistake nonetheless. We >> don't want to funnel plugin logging (for a plugin declaring its own >> slf4j dependencies) into Maven logging. For one, that's not the >> *current* behavior as Maven logging and plugin logging (depending on >> slf4j) are obviously independent. For two, attempts at such integration >> quickly become insurmountably complex. Logging integration between >> Maven and a pluging declaring its own slf4j dependencies is not needed >> and certainly not worth the effort. >> >> If unconvinced, I suggest we study concrete examples. >> >> -- >> Ceki >> 65% of statistics are made up on the spot >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
