2012/10/11 Benson Margulies <bimargul...@gmail.com>: > 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". looks to be an issue an issue with extension in maven 2 for webdav. Is there any issue for that ? > > > >> >> >> 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 >
-- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
