Couldn't we use the shading plugin to not expose the original implementation (logback, log4k, whatever ..) but a repackaged one to avoid conflicts with plugins which may bring (intentionally or by error) its own impl ? ? Perhaps my idea is just stupid ...
Arnaud On Sat, Dec 1, 2012 at 11:02 AM, Mark Struberg <strub...@yahoo.de> wrote: > what is complex with say am openjpa enhancer mojo? > Still this will break depending what the project configures in it's > persistence.xml. > > Just an idea for now: > The safe route might be a plugin-plugin annotatation which tells us > 'plugin uses slf4j' in that case it gets exposed, in other cases it doesn't. > > Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will > evaluate it and add slf4j injection support for those plugins. > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Benson Margulies <bimargul...@gmail.com> > > To: Maven Developers List <dev@maven.apache.org> > > Cc: > > Sent: Friday, November 30, 2012 10:15 PM > > Subject: Re: [VOTE] Maven 3.1.0 > > > > At the end of the day, either Maven uses a standard logging API inside > > plugins, or it does not. Using a standard logging API has giant > > advantages - but it can inconvenience people integrating complex code > > via plugins. > > > > In this thread, there are two approaches to removing that > > inconvenience: a plugin annotation that changing the logging > > integration, and use of forking. Both work. I have some sympathy for > > the view that anything complex enough to care should fork. When people > > integrate big complex things, it has unpleasant consequences like > > System.exit() calls. > > > > So I'm entirely +1 for the code as it stands, and I see adding an > > annotation or something to avoid injecting the logging back end as a > > nice to have. As I wrote before, I'd feel better about the 'stick a > > fork' in it prescription if we had better reusable forking code. > > > > --------------------------------------------------------------------- > > 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 > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
