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
