On Oct 11, 2012, at 4:29 PM, Mark Struberg <strub...@yahoo.de> wrote:
> > 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. > We've not seen this integrating SLF4J and Logback with m2e which is probably the most widely distributed integration of Maven. > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
