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
