Oki, back from my IT testing orgy with slf4j.
I managed to break the build, but the good news: it was actually much harder than I thought. Plus I found a pretty easy workaround! First an analysis from the classloader perspective. Whatever you configure as slf4j-api version in any plugin will not be used because the slf4j-api from the core-realm will always be taken. Also the org.slf4j.impl.StaticLoggerBinder will only be picked up from the core realm as far as I've seen. Thus we can rule out any problems between slf4j-api and the logger backend. Of course this means that any configured logging backends of your plugin will not be used if I observed this correctly. Another minor issue is that we currently have slf4j-nop in our trunk which just swallows all slf4j logs at all. We should use slf4j-simple instead. Now for the client side: using a jcl-to-slf4j jar 1.5.8 This gets perfectly picked up by the plugin classloader and will be used. As already reported by Ceki the LocationAwareLogger is the most problematic API. If any funnel uses a LocationAwareLogger then maven blows up. But happily the LocationAwareLogger method only gets invoked if the configured logging backend is a LocationAwareLogger. And slf4j-simple isn't such a thing, right? If a user switches to logback and a more advanced logging config then you are back to maven blurp. Now the workaround. It works if you just add a <dependency> with a newer version to the plugin configuration. Thats for sure not a show stopper. We just need to document it in a FAQ. I gonna refine the IT and check it in in the next days. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <strub...@yahoo.de> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Thursday, October 11, 2012 5:56 PM > Subject: Re: SLF4J integration > > Benson, I already pointed to a few plugins which are broken with trunk. And > OpenJPA is not a highly out of the world usage scenario! > > Please tell me what exactly you think you would gain from exposing slf4j to > plugins and then we can discuss about if this is possibly without breaking > stuff. > > Again: this is not a discussion about different design decisions - we are > talking about bombing out with Exceptions for approx 5% of all builds! > > > It might be _perfectly_ fine to use slf4j internally. But by exposing it to > the > plugin classpath we do gain almost nothing and get into class hell. We could > just remove it from the Classworld core realm and then we would be fine as > well. > > > Btw, instead of switching hardcoded from log4j to hardcoded slf4j we again do > not gain much. I'd expect a pluggable/configurable mechanism here. > > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Benson Margulies <bimargul...@gmail.com> >> To: Maven Developers List <dev@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> >> Cc: >> Sent: Thursday, October 11, 2012 5:16 PM >> Subject: Re: SLF4J integration >> >> On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg <strub...@yahoo.de> > wrote: >>> Benson, it's a pity that this happened to you, and I blame it on > some >> plugin bug which should get fixed. Forcing a maven upgrade just because >> something is buggy is not a serious option. It's ok for well intended > new >> features, but not if it's just a matter of a bug. >>> >>> And knowingly breaking tons of existing builds is not an option > neither >> imo. And this is what Jasons commit did. And it was not even a commented > feature >> commit but a 'side effect' of the (btw broken as well afaik) > @Inject >> enabling commit. This would be a nightmare for thousands of company users > which >> are not allowed to update their build infrastructure that easily. >> >> 'tons of existing builds'? Mark, you continue to claim that slf4j >> dependencies are think on the ground, but offer no evidence. And it's >> not a 'break', in my opinion, to say that a X.Y release is not >> completely backwards compatible. No one is forced to use the new >> version. They can transition when its convenient. >> >> Having flexibility to change the logging back end is a positive value >> to the overall maven platform, and i'm prepared to go along with this >> plan, which accepts some possible inconvenience to some adopters as >> the price of it. If there were lots of other people agreeing with you, >> I'd be OK with looking for a stronger isolation technique to insulate >> the maven core's decision about how to route log messages from the >> decision of any one plugin. Right now, it appears (and perhaps I'm >> misreading the sense of the discussion) that you're the only person >> unhappy with this plan. >> >> Also, could someone please clarify for me whether slf4j changes have >> been committed to the trunk, or merely to a branch? I'm afraid that >> I've got two topics mixed up in my head. >> >> As for my problem with the buildnumber build, until someone explains >> it, we know nothing. I put it out there as evidence that something, >> somewhere, in the build of that touched sl4fj long before JvZ did >> anything discussed here, and I thought that perhaps someone might be >> interested in working out "what". >> >> >> >>> >>> >>> To short version: the current trunk is broken and there is no benefit > by >> exposing slf4j in the near future. >>> >>> The slightly longer version: >>> >>> Any builds with a plugin dependency on slf4j < 1.6 is broken with > the >> current trunk and will blow up. Even Ceki admitted that. >>> >>> There is a possible fix by isolating all plugins which provide slf4j >> logging themself. But then those plugins will NOT use mavens slf4j logging >> anymore but their own. So for all those plugins the slf4j provided by maven > is >> useless. >>> >>> >>> And if a plugin uses slf4j for logging and does NOT provide an own > slf4j >> backend, then it will be broken with _all_ already existing maven versions. > And >> there is not even a migration path between those 2 modes. >>> >>> If we expose the slf4j api now, then you would need to wait > approximately 2 >> years before any plugins can start using it. 2 years is a long time in the >> computer industry... >>> >>> >>> Again, this has _nothing_ to do with slf4j! I would also be -1 for > exposing >> commons-logging, log4j or any other existing logging framework which could > exist >>> >>> in user plugins! They just introduce classloader problems alltogether. >>> >>> >>> The only framework which might be ok would java.util.logging. Yea jul > sucks >> as hell and if used badly it creates permgen issues and other side effects. > But >> at least it doesnt create class clashes. >>> >>> The best we could do is to provide a maven.plugin.Logger backend for > slf4j. >>> >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> ----- Original Message ----- >>>> From: Benson Margulies <bimargul...@gmail.com> >>>> To: Maven Developers List <dev@maven.apache.org>; Mark > Struberg >> <strub...@yahoo.de> >>>> Cc: >>>> Sent: Thursday, October 11, 2012 2:14 PM >>>> Subject: Re: SLF4J integration >>>> >>>> 1. I have an example of something. I don't quite know what. >>>> >>>> I went to release the buildnumber-maven-plugin from the mojo > project, >>>> using 2.2.1. I got a murky error about slf4j, followed by a > failure to >>>> find a 'dav' transport. >>>> >>>> So I patched in wagon-dav, and I now the only problem was the > slf4j >>>> complaint. So I want with 3.0.4, and all was well. >>>> >>>> 2. Let's keep this in perspective: worst case: some plugin >> doesn't >>>> work with 3.1 until adjusted. Unless the claim is that there is no >>>> simple or practical adjustment fot some reasonable case, this >> doesn't >>>> bother me. >>>> >>>> > --------------------------------------------------------------------- >>>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
