You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Struberg <st...@yahoo.de> on 2012/12/01 11:02:41 UTC
Re: [VOTE] Maven 3.1.0
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 <bi...@gmail.com>
> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Maven 3.1.0
Posted by Mark Struberg <st...@yahoo.de>.
In that case the users cannot use plain slf4j APIs and we would not gain anything anyway.
This would have the same effect like not exposing the classes in our core realm at all.
LieGrue,
strub
>________________________________
> From: Arnaud Héritier <ah...@gmail.com>
>To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
>Sent: Saturday, December 1, 2012 11:20 AM
>Subject: Re: [VOTE] Maven 3.1.0
>
>
>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 <st...@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 <bi...@gmail.com>
>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
>--
>
>-----
>Arnaud Héritier
>http://aheritier.net
>Mail/GTalk: aheritier AT gmail DOT com
>Twitter/Skype : aheritier
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Maven 3.1.0
Posted by Arnaud Héritier <ah...@gmail.com>.
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 <st...@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 <bi...@gmail.com>
> > To: Maven Developers List <de...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier