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. 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
