Logger name for mojo

2012-11-15 Thread Olivier Lamy 
Hi,
Currently logger for all mojos is the DefaultPluginManager logger.
So it's a bit hard to have filtering per plugin (i.e. only compiler in
debug etc..)

So I'd like to change that to be able to customize mojo logging.
My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
to debug.

Makes sense ?

The code to change is here:
https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445

WDYT ?

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Benson Margulies 
On Thu, Nov 15, 2012 at 8:18 AM, Olivier Lamy ol...@apache.org wrote:
 Hi,
 Currently logger for all mojos is the DefaultPluginManager logger.
 So it's a bit hard to have filtering per plugin (i.e. only compiler in
 debug etc..)

 So I'd like to change that to be able to customize mojo logging.
 My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
 org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
 for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
 to debug.

 Makes sense ?

+1


 The code to change is here:
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445

 WDYT ?

 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 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

Re: Logger name for mojo

2012-11-15 Thread Jason van Zyl 

On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:

 Hi,
 Currently logger for all mojos is the DefaultPluginManager logger.
 So it's a bit hard to have filtering per plugin (i.e. only compiler in
 debug etc..)
 
 So I'd like to change that to be able to customize mojo logging.
 My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
 org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
 for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
 to debug.
 
 Makes sense ?
 

Why not use the standard way of using the class name of the plugin and using 
standard techniques for filtering? 

 The code to change is here:
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
 
 WDYT ?
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder  CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

I never make the mistake of arguing with people for whose opinions I have no 
respect.

-- Edward Gibbon

Re: Logger name for mojo

2012-11-15 Thread Benson Margulies 
On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl ja...@tesla.io wrote:

 On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:

 Hi,
 Currently logger for all mojos is the DefaultPluginManager logger.
 So it's a bit hard to have filtering per plugin (i.e. only compiler in
 debug etc..)

 So I'd like to change that to be able to customize mojo logging.
 My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
 org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
 for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
 to debug.

 Makes sense ?


 Why not use the standard way of using the class name of the plugin and using 
 standard techniques for filtering?

Because Maven Users know the GAV of plugins, and don't know, and
shouldn't need to know, the class names.

This change addresses a real problem: when something doesn't work, we
tell users to use -X, and they get immediately drowned in irrelevance.
If we could tell them to log 'just one plugin' in some sensible,
logical, way, they would be less frustrated. Using this scheme of
olamy's has that effect.




 The code to change is here:
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445

 WDYT ?

 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 I never make the mistake of arguing with people for whose opinions I have no 
 respect.

 -- Edward Gibbon






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Jason van Zyl 

On Nov 15, 2012, at 8:33 AM, Benson Margulies bimargul...@gmail.com wrote:

 On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl ja...@tesla.io wrote:
 
 On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:
 
 Hi,
 Currently logger for all mojos is the DefaultPluginManager logger.
 So it's a bit hard to have filtering per plugin (i.e. only compiler in
 debug etc..)
 
 So I'd like to change that to be able to customize mojo logging.
 My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
 org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
 for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
 to debug.
 
 Makes sense ?
 
 
 Why not use the standard way of using the class name of the plugin and using 
 standard techniques for filtering?
 
 Because Maven Users know the GAV of plugins, and don't know, and
 shouldn't need to know, the class names.
 

Yes, but we do. If we wanted to provide domain specific logging it would be our 
job to do the mapping between class names and filters. It's just very 
non-standard to create logger names based on something other than class names.

 This change addresses a real problem: when something doesn't work, we
 tell users to use -X, and they get immediately drowned in irrelevance.
 If we could tell them to log 'just one plugin' in some sensible,
 logical, way, they would be less frustrated. Using this scheme of
 olamy's has that effect.
 

I agree, but to achieve that does not require doing something non-standard. For 
us a simple filter of any number of class names is easy, integration into 
larger systems that use the common pattern of class name also do not become 
problematic.

I agree that filtering is a nice feature, it can be done using the standard 
practice of using the class name.

 
 
 
 The code to change is here:
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
 
 WDYT ?
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 I never make the mistake of arguing with people for whose opinions I have no 
 respect.
 
 -- Edward Gibbon
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder  CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

Re: Logger name for mojo

2012-11-15 Thread Gary Gregory 
On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl ja...@tesla.io wrote:


 On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:

  Hi,
  Currently logger for all mojos is the DefaultPluginManager logger.
  So it's a bit hard to have filtering per plugin (i.e. only compiler in
  debug etc..)
 
  So I'd like to change that to be able to customize mojo logging.
  My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
  org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
  for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
  to debug.
 
  Makes sense ?
 

 Why not use the standard way of using the class name of the plugin and
 using standard techniques for filtering?


If you always use . as the separator (not :), you will be able to use
most logging framework's hierarchical logging features.

Gary



  The code to change is here:
 
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
 
  WDYT ?
 
  Thanks
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 I never make the mistake of arguing with people for whose opinions I have
 no respect.

 -- Edward Gibbon








-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Logger name for mojo

2012-11-15 Thread Mirko Friedenhagen 
Hello,

not a Maven-developer, but here are my thoughts: I think Jason's
solution using package.class conventions is more standard. When
someone asks for help, telling them to call (assuming -L would be the
option to set the loggers):

mvn -L org.apache.maven.plugins.release,org.apache.maven.shared.release
release:prepare
is less vodoo then
mvn -L org.apache.maven.plugins:maven-release-plugin release:prepare.

Every class which uses logging via slf4j could just use the standard
way of defining the logger via LoggerFactory.getLogger(FooMojo.class)
*and* refactoring would be easier. Or did you want to inject the
logger via an annotation during compile instead? +1 for using at least
dots instead of colon because of easier hierarchy parsing :-).

Regards Mirko

On Thu, Nov 15, 2012 at 2:40 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl ja...@tesla.io wrote:


 On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:

  Hi,
  Currently logger for all mojos is the DefaultPluginManager logger.
  So it's a bit hard to have filtering per plugin (i.e. only compiler in
  debug etc..)
 
  So I'd like to change that to be able to customize mojo logging.
  My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
  org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
  for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
  to debug.
 
  Makes sense ?
 

 Why not use the standard way of using the class name of the plugin and
 using standard techniques for filtering?


 If you always use . as the separator (not :), you will be able to use
 most logging framework's hierarchical logging features.

 Gary



  The code to change is here:
 
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
 
  WDYT ?
 
  Thanks
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 I never make the mistake of arguing with people for whose opinions I have
 no respect.

 -- Edward Gibbon








 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Jason van Zyl 
This is simply one of the pros for a logging framework which is domain specific 
logging. I'll add it to the list.

On Nov 15, 2012, at 9:00 AM, Mirko Friedenhagen mfriedenha...@gmail.com wrote:

 Hello,
 
 not a Maven-developer, but here are my thoughts: I think Jason's
 solution using package.class conventions is more standard. When
 someone asks for help, telling them to call (assuming -L would be the
 option to set the loggers):
 
 mvn -L org.apache.maven.plugins.release,org.apache.maven.shared.release
 release:prepare
 is less vodoo then
 mvn -L org.apache.maven.plugins:maven-release-plugin release:prepare.
 
 Every class which uses logging via slf4j could just use the standard
 way of defining the logger via LoggerFactory.getLogger(FooMojo.class)
 *and* refactoring would be easier. Or did you want to inject the
 logger via an annotation during compile instead? +1 for using at least
 dots instead of colon because of easier hierarchy parsing :-).
 
 Regards Mirko
 
 On Thu, Nov 15, 2012 at 2:40 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl ja...@tesla.io wrote:
 
 
 On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:
 
 Hi,
 Currently logger for all mojos is the DefaultPluginManager logger.
 So it's a bit hard to have filtering per plugin (i.e. only compiler in
 debug etc..)
 
 So I'd like to change that to be able to customize mojo logging.
 My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
 org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
 for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
 to debug.
 
 Makes sense ?
 
 
 Why not use the standard way of using the class name of the plugin and
 using standard techniques for filtering?
 
 
 If you always use . as the separator (not :), you will be able to use
 most logging framework's hierarchical logging features.
 
 Gary
 
 
 
 The code to change is here:
 
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
 
 WDYT ?
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 I never make the mistake of arguing with people for whose opinions I have
 no respect.
 
 -- Edward Gibbon
 
 
 
 
 
 
 
 
 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder  CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa

Re: Logger name for mojo

2012-11-15 Thread Jason van Zyl 
On Nov 15, 2012, at 8:40 AM, Gary Gregory garydgreg...@gmail.com wrote:

 On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl ja...@tesla.io wrote:
 
 
 On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:
 
 Hi,
 Currently logger for all mojos is the DefaultPluginManager logger.
 So it's a bit hard to have filtering per plugin (i.e. only compiler in
 debug etc..)
 
 So I'd like to change that to be able to customize mojo logging.
 My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
 org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
 for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
 to debug.
 
 Makes sense ?
 
 
 Why not use the standard way of using the class name of the plugin and
 using standard techniques for filtering?
 
 
 If you always use . as the separator (not :), you will be able to use
 most logging framework's hierarchical logging features.
 

Right, another reason to use something standard. Logback does not recognize the 
: for hierarchies.

So would you agree that using class names accepted as a best practice and does 
not limit any sort of filtering?

 Gary
 
 
 
 The code to change is here:
 
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
 
 WDYT ?
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 I never make the mistake of arguing with people for whose opinions I have
 no respect.
 
 -- Edward Gibbon
 
 
 
 
 
 
 
 
 -- 
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Thanks,

Jason

--
Jason van Zyl
Founder  CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: Logger name for mojo

2012-11-15 Thread Benson Margulies 
I can see arguments on both sides of this question of how to pick the
logging ID. I'll start with my corner.

The convention of having a logger for each class, named after the
class, is just that. A convention. It serves well in many cases.
However, in my opinion, it threatens to become a sort of cargo-cult
law of nature.

The various logging frameworks all permit arbitrary names (with
separators) for loggers, and they permit it for a reason. Sometimes,
there is a good reason to control logging on an axis that is not class
names.

I've had a few occasions where I really wanted to be able to control
logging on some other logical axis, so I created a logger with some
suitable name, and I used it in multiple classes. Just as in olamy's
proposal.

This scheme makes it trivial for us to allow end-users to control
logging by plugin, since we don't need any additional framework, data
structure, or mapping.

The other side of the coin, as I see it, is that developers also want
to do fine-grained logging control, and, in almost all cases, class
names serve well. So, something like Jason's scheme of using
conventional class names, but providing a mapping, would appear to
serve both needs.

However ... the mapping in question seems to me to be inevitably tied
to the selection of one logging backend, unless we want to invent some
sort of slf4j-ish means of mapping. I am most familiar with log4j, so
I'll be concrete with the issue as it would arise there. If we use
class-name loggers, and provide a mapping that maps from G/AV to
packages or classes, something has to take this mapping and use it to
generate a log4j configuration. I presume that the same would apply to
logback or whatever else.

That seems a lot of work to me. So, my opinion is that olamy's scheme
is better, because it puts the needs of end-users ahead of the needs
of devs.

However, if we only care about solving G/A/V control for actual
end-users of Maven, and not users of complex embeds, then my view gets
weaker. Once we choose a logging back-end for Apache Maven, it's not
going to be very hard to implement the control mapping for that one
back-end.

So, weirdly, I find myself arguing against Jason on behalf of the use
case he's usually arguing for.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Jason van Zyl 

On Nov 15, 2012, at 11:08 AM, Benson Margulies bimargul...@gmail.com wrote:

 I can see arguments on both sides of this question of how to pick the
 logging ID. I'll start with my corner.
 
 The convention of having a logger for each class, named after the
 class, is just that. A convention. It serves well in many cases.
 However, in my opinion, it threatens to become a sort of cargo-cult
 law of nature.
 
 The various logging frameworks all permit arbitrary names (with
 separators) for loggers, and they permit it for a reason. Sometimes,
 there is a good reason to control logging on an axis that is not class
 names.
 

I have never been limited in any domain specific way by using the class name. 
In every single case, without exception, a mapping can be made from something 
to the class name to create filters. Doing it differently potentially 
interferes with all known ways of doing this. I have never seen something other 
than class names be used, and I have also never seen that as a limitation in 
any logging context.

 I've had a few occasions where I really wanted to be able to control
 logging on some other logical axis, so I created a logger with some
 suitable name, and I used it in multiple classes. Just as in olamy's
 proposal.
 
 This scheme makes it trivial for us to allow end-users to control
 logging by plugin, since we don't need any additional framework, data
 structure, or mapping.
 
 The other side of the coin, as I see it, is that developers also want
 to do fine-grained logging control, and, in almost all cases, class
 names serve well. So, something like Jason's scheme of using
 conventional class names, but providing a mapping, would appear to
 serve both needs.
 
 However ... the mapping in question seems to me to be inevitably tied
 to the selection of one logging backend, unless we want to invent some
 sort of slf4j-ish means of mapping. I am most familiar with log4j, so
 I'll be concrete with the issue as it would arise there. If we use
 class-name loggers, and provide a mapping that maps from G/AV to
 packages or classes, something has to take this mapping and use it to
 generate a log4j configuration. I presume that the same would apply to
 logback or whatever else.
 
 That seems a lot of work to me. So, my opinion is that olamy's scheme
 is better, because it puts the needs of end-users ahead of the needs
 of devs.
 
 However, if we only care about solving G/A/V control for actual
 end-users of Maven, and not users of complex embeds, then my view gets
 weaker. Once we choose a logging back-end for Apache Maven, it's not
 going to be very hard to implement the control mapping for that one
 back-end.
 
 So, weirdly, I find myself arguing against Jason on behalf of the use
 case he's usually arguing for.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder  CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language

Re: Logger name for mojo

2012-11-15 Thread Olivier Lamy 
2012/11/15 Benson Margulies bimargul...@gmail.com:
 I can see arguments on both sides of this question of how to pick the
 logging ID. I'll start with my corner.

 The convention of having a logger for each class, named after the
 class, is just that. A convention. It serves well in many cases.
 However, in my opinion, it threatens to become a sort of cargo-cult
 law of nature.

 The various logging frameworks all permit arbitrary names (with
 separators) for loggers, and they permit it for a reason. Sometimes,
 there is a good reason to control logging on an axis that is not class
 names.

 I've had a few occasions where I really wanted to be able to control
 logging on some other logical axis, so I created a logger with some
 suitable name, and I used it in multiple classes. Just as in olamy's
 proposal.

 This scheme makes it trivial for us to allow end-users to control
 logging by plugin, since we don't need any additional framework, data
 structure, or mapping.

 The other side of the coin, as I see it, is that developers also want
 to do fine-grained logging control, and, in almost all cases, class
 names serve well. So, something like Jason's scheme of using
 conventional class names, but providing a mapping, would appear to
 serve both needs.

 However ... the mapping in question seems to me to be inevitably tied
 to the selection of one logging backend, unless we want to invent some
 sort of slf4j-ish means of mapping. I am most familiar with log4j, so
 I'll be concrete with the issue as it would arise there. If we use
 class-name loggers, and provide a mapping that maps from G/AV to
 packages or classes, something has to take this mapping and use it to
 generate a log4j configuration. I presume that the same would apply to
 logback or whatever else.

 That seems a lot of work to me. So, my opinion is that olamy's scheme
 is better, because it puts the needs of end-users ahead of the needs
 of devs.

can be easy to make that configurable with an option ? (default could
be user oriented).
As the stuff is done in only one class (DefaultPluginManager).




 However, if we only care about solving G/A/V control for actual
 end-users of Maven, and not users of complex embeds, then my view gets
 weaker. Once we choose a logging back-end for Apache Maven, it's not
 going to be very hard to implement the control mapping for that one
 back-end.

 So, weirdly, I find myself arguing against Jason on behalf of the use
 case he's usually arguing for.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Benson Margulies 
On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl ja...@tesla.io wrote:

 On Nov 15, 2012, at 11:08 AM, Benson Margulies bimargul...@gmail.com wrote:

 I can see arguments on both sides of this question of how to pick the
 logging ID. I'll start with my corner.

 The convention of having a logger for each class, named after the
 class, is just that. A convention. It serves well in many cases.
 However, in my opinion, it threatens to become a sort of cargo-cult
 law of nature.

 The various logging frameworks all permit arbitrary names (with
 separators) for loggers, and they permit it for a reason. Sometimes,
 there is a good reason to control logging on an axis that is not class
 names.


 I have never been limited in any domain specific way by using the class name. 
 In every single case, without exception, a mapping can be made from something 
 to the class name to create filters. Doing it differently potentially 
 interferes with all known ways of doing this. I have never seen something 
 other than class names be used, and I have also never seen that as a 
 limitation in any logging context.

Here's the situation I recall in which this came up..

A complex body of code, involving many classes, implements a decoder
for an 'averaged perceptron named entity extractor'. In some
situations, there are logging messages that allow a developer to
monitor how the algorithm is dealing with a particular input. These
messages are scattered over many classes, and in these classes, only
*some* of the potential logging messages are relevant to the task of
tracing the behavior of the decoder.

Controlling by class wasn't going to work, because it would end up
turning on undesirable noise along with the desired information.
Controlling by level would have worked if I was using a logging
framework that supported custom levels. It has occasionally struck me
as odd that this is a rare feature of logging frameworks. slf4j, for
example, precludes it.

So, I defined a single 'decoder trace' logger, and made all of these
messages post to it. I could then turn these on and off independently
of all of the others.

When I first responded to this thread, my instinct was to see the
G:A:V 'axis' as analogous. As I think about it now, my view is that
there is an analogy, but that neither olamy's proposal nor the 'usual
thing+map' fixes it.

When developing a plugin, I wish that I could make a very clear
distinction between two classes of messages: messages that provided
additional detail intended for end users, and messages that are only
there for developers. Arguably, what I am complaining about is that
the existing Mojo logging API has too few levels; I want to
distinguish 'error', 'info', 'detail', and 'debug'. Error and info
would be displayed by default, 'detail' via (e.g.) -X, and 'debug' by
-XX.

Pretty clearly, this is orthogonal to the debate at hand, so I'm going
to stop typing and see what others have to write.





 I've had a few occasions where I really wanted to be able to control
 logging on some other logical axis, so I created a logger with some
 suitable name, and I used it in multiple classes. Just as in olamy's
 proposal.

 This scheme makes it trivial for us to allow end-users to control
 logging by plugin, since we don't need any additional framework, data
 structure, or mapping.

 The other side of the coin, as I see it, is that developers also want
 to do fine-grained logging control, and, in almost all cases, class
 names serve well. So, something like Jason's scheme of using
 conventional class names, but providing a mapping, would appear to
 serve both needs.

 However ... the mapping in question seems to me to be inevitably tied
 to the selection of one logging backend, unless we want to invent some
 sort of slf4j-ish means of mapping. I am most familiar with log4j, so
 I'll be concrete with the issue as it would arise there. If we use
 class-name loggers, and provide a mapping that maps from G/AV to
 packages or classes, something has to take this mapping and use it to
 generate a log4j configuration. I presume that the same would apply to
 logback or whatever else.

 That seems a lot of work to me. So, my opinion is that olamy's scheme
 is better, because it puts the needs of end-users ahead of the needs
 of devs.

 However, if we only care about solving G/A/V control for actual
 end-users of Maven, and not users of complex embeds, then my view gets
 weaker. Once we choose a logging back-end for Apache Maven, it's not
 going to be very hard to implement the control mapping for that one
 back-end.

 So, weirdly, I find myself arguing against Jason on behalf of the use
 case he's usually arguing for.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder  CTO, Sonatype

Re: Logger name for mojo

2012-11-15 Thread Jason van Zyl 
It looks like Markers[1] are supported in SLF4J and can be used in conjunction 
with the class name to gain another axis of control:

[1] http://www.slf4j.org/apidocs/org/slf4j/Marker.html

So this is probably the way it should be done as you don't lose the hierarchy 
and if you want an additional axis of control you can add whatever you like.

On Nov 15, 2012, at 1:02 PM, Benson Margulies bimargul...@gmail.com wrote:

 On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl ja...@tesla.io wrote:
 
 On Nov 15, 2012, at 11:08 AM, Benson Margulies bimargul...@gmail.com wrote:
 
 I can see arguments on both sides of this question of how to pick the
 logging ID. I'll start with my corner.
 
 The convention of having a logger for each class, named after the
 class, is just that. A convention. It serves well in many cases.
 However, in my opinion, it threatens to become a sort of cargo-cult
 law of nature.
 
 The various logging frameworks all permit arbitrary names (with
 separators) for loggers, and they permit it for a reason. Sometimes,
 there is a good reason to control logging on an axis that is not class
 names.
 
 
 I have never been limited in any domain specific way by using the class 
 name. In every single case, without exception, a mapping can be made from 
 something to the class name to create filters. Doing it differently 
 potentially interferes with all known ways of doing this. I have never seen 
 something other than class names be used, and I have also never seen that as 
 a limitation in any logging context.
 
 Here's the situation I recall in which this came up..
 
 A complex body of code, involving many classes, implements a decoder
 for an 'averaged perceptron named entity extractor'. In some
 situations, there are logging messages that allow a developer to
 monitor how the algorithm is dealing with a particular input. These
 messages are scattered over many classes, and in these classes, only
 *some* of the potential logging messages are relevant to the task of
 tracing the behavior of the decoder.
 
 Controlling by class wasn't going to work, because it would end up
 turning on undesirable noise along with the desired information.
 Controlling by level would have worked if I was using a logging
 framework that supported custom levels. It has occasionally struck me
 as odd that this is a rare feature of logging frameworks. slf4j, for
 example, precludes it.
 
 So, I defined a single 'decoder trace' logger, and made all of these
 messages post to it. I could then turn these on and off independently
 of all of the others.
 
 When I first responded to this thread, my instinct was to see the
 G:A:V 'axis' as analogous. As I think about it now, my view is that
 there is an analogy, but that neither olamy's proposal nor the 'usual
 thing+map' fixes it.
 
 When developing a plugin, I wish that I could make a very clear
 distinction between two classes of messages: messages that provided
 additional detail intended for end users, and messages that are only
 there for developers. Arguably, what I am complaining about is that
 the existing Mojo logging API has too few levels; I want to
 distinguish 'error', 'info', 'detail', and 'debug'. Error and info
 would be displayed by default, 'detail' via (e.g.) -X, and 'debug' by
 -XX.
 
 Pretty clearly, this is orthogonal to the debate at hand, so I'm going
 to stop typing and see what others have to write.
 
 
 
 
 
 I've had a few occasions where I really wanted to be able to control
 logging on some other logical axis, so I created a logger with some
 suitable name, and I used it in multiple classes. Just as in olamy's
 proposal.
 
 This scheme makes it trivial for us to allow end-users to control
 logging by plugin, since we don't need any additional framework, data
 structure, or mapping.
 
 The other side of the coin, as I see it, is that developers also want
 to do fine-grained logging control, and, in almost all cases, class
 names serve well. So, something like Jason's scheme of using
 conventional class names, but providing a mapping, would appear to
 serve both needs.
 
 However ... the mapping in question seems to me to be inevitably tied
 to the selection of one logging backend, unless we want to invent some
 sort of slf4j-ish means of mapping. I am most familiar with log4j, so
 I'll be concrete with the issue as it would arise there. If we use
 class-name loggers, and provide a mapping that maps from G/AV to
 packages or classes, something has to take this mapping and use it to
 generate a log4j configuration. I presume that the same would apply to
 logback or whatever else.
 
 That seems a lot of work to me. So, my opinion is that olamy's scheme
 is better, because it puts the needs of end-users ahead of the needs
 of devs.
 
 However, if we only care about solving G/A/V control for actual
 end-users of Maven, and not users of complex embeds, then my view gets
 weaker. Once we choose a logging back-end for Apache Maven, it's not
 going to be

Re: [VOTE] Release Maven Assembly Plugin version 2.4

2012-11-15 Thread Olivier Lamy 
+1


2012/11/15 Dennis Lundberg denn...@apache.org:
 Hi,

 We solved 29 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=18308

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11126status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-039/
 https://repository.apache.org/content/repositories/maven-039/org/apache/maven/plugins/maven-assembly-plugin/2.4/maven-assembly-plugin-2.4-source-release.zip

 Staging site (wait for the sync):
 http://maven.apache.org/plugins/maven-assembly-plugin-2.4/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1
 --
 Dennis Lundberg

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[VOTE] Maven Compiler Plugin 3.0 and maven-shared-incremental 1.0

2012-11-15 Thread Olivier Lamy 
Hi,
I'd like to release Maven Compiler 3.0
We fixed 9 issues.
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18537styleName=TextprojectId=11130Create=Create

Staging repository:
https://repository.apache.org/content/repositories/maven-040/

https://repository.apache.org/content/repositories/maven-040/org/apache/maven/plugins/maven-compiler-plugin/3.0/maven-compiler-plugin-3.0-source-release.zip

https://repository.apache.org/content/repositories/maven-040/org/apache/maven/shared/maven-shared-incremental/1.0/maven-shared-incremental-1.0-source-release.zip

Staging site (wait for the sync):
http://maven.apache.org/plugins/maven-compiler-plugin-3.0
http://maven.apache.org/shared/maven-shared-incremental

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


Thanks,
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Chris Graham 
If you're doing down this way, I would strongly recommend the ability not
only to log specific packages, but to be able to set their logging level as
well.

For example, from WebSphere:

*=info:com.ibm.ws.webcontainer.*=all:com.ibm.ws.wswebcontainer.*=all:com.ibm.wsspi.webcontainer.*=all:HTTPChannel=all:GenericBNF=all

or from an eclipse.options file:

com.ibm.ws.sca.rapiddeploy.style/debug=true
com.ibm.ws.sca.rapiddeploy.style/trace=true
com.ibm.ws.sca.rapiddeploy.style/event=true
com.ibm.ws.sca.rapiddeploy.style/info=true

com.ibm.ws.sca.headless/debug=true
com.ibm.ws.sca.headless/debug/trace=true
com.ibm.ws.sca.headless/debug/event=true
com.ibm.ws.sca.headless/debug/info=true


At this level, you will need to delve into the specifics of formats.

Personally, I perfer the WAS style.

See:

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/rtrb_enabletrc.html

for a better discussion on the formats and syntax. If nothing else, it
should provide some food for thought.

-Chris



On Fri, Nov 16, 2012 at 5:05 AM, Jason van Zyl ja...@tesla.io wrote:

 It looks like Markers[1] are supported in SLF4J and can be used in
 conjunction with the class name to gain another axis of control:

 [1] http://www.slf4j.org/apidocs/org/slf4j/Marker.html

 So this is probably the way it should be done as you don't lose the
 hierarchy and if you want an additional axis of control you can add
 whatever you like.

 On Nov 15, 2012, at 1:02 PM, Benson Margulies bimargul...@gmail.com
 wrote:

  On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl ja...@tesla.io wrote:
 
  On Nov 15, 2012, at 11:08 AM, Benson Margulies bimargul...@gmail.com
 wrote:
 
  I can see arguments on both sides of this question of how to pick the
  logging ID. I'll start with my corner.
 
  The convention of having a logger for each class, named after the
  class, is just that. A convention. It serves well in many cases.
  However, in my opinion, it threatens to become a sort of cargo-cult
  law of nature.
 
  The various logging frameworks all permit arbitrary names (with
  separators) for loggers, and they permit it for a reason. Sometimes,
  there is a good reason to control logging on an axis that is not class
  names.
 
 
  I have never been limited in any domain specific way by using the class
 name. In every single case, without exception, a mapping can be made from
 something to the class name to create filters. Doing it differently
 potentially interferes with all known ways of doing this. I have never seen
 something other than class names be used, and I have also never seen that
 as a limitation in any logging context.
 
  Here's the situation I recall in which this came up..
 
  A complex body of code, involving many classes, implements a decoder
  for an 'averaged perceptron named entity extractor'. In some
  situations, there are logging messages that allow a developer to
  monitor how the algorithm is dealing with a particular input. These
  messages are scattered over many classes, and in these classes, only
  *some* of the potential logging messages are relevant to the task of
  tracing the behavior of the decoder.
 
  Controlling by class wasn't going to work, because it would end up
  turning on undesirable noise along with the desired information.
  Controlling by level would have worked if I was using a logging
  framework that supported custom levels. It has occasionally struck me
  as odd that this is a rare feature of logging frameworks. slf4j, for
  example, precludes it.
 
  So, I defined a single 'decoder trace' logger, and made all of these
  messages post to it. I could then turn these on and off independently
  of all of the others.
 
  When I first responded to this thread, my instinct was to see the
  G:A:V 'axis' as analogous. As I think about it now, my view is that
  there is an analogy, but that neither olamy's proposal nor the 'usual
  thing+map' fixes it.
 
  When developing a plugin, I wish that I could make a very clear
  distinction between two classes of messages: messages that provided
  additional detail intended for end users, and messages that are only
  there for developers. Arguably, what I am complaining about is that
  the existing Mojo logging API has too few levels; I want to
  distinguish 'error', 'info', 'detail', and 'debug'. Error and info
  would be displayed by default, 'detail' via (e.g.) -X, and 'debug' by
  -XX.
 
  Pretty clearly, this is orthogonal to the debate at hand, so I'm going
  to stop typing and see what others have to write.
 
 
 
 
 
  I've had a few occasions where I really wanted to be able to control
  logging on some other logical axis, so I created a logger with some
  suitable name, and I used it in multiple classes. Just as in olamy's
  proposal.
 
  This scheme makes it trivial for us to allow end-users to control
  logging by plugin, since we don't need any additional framework, data
  structure, or mapping.
 
  The other side of the coin,

Re: [VOTE] Release Apache Maven Wagon 2.0

2012-11-15 Thread Kamlesh Shah 
Check this link for the same: 
http://forums.gradle.org/gradle/topics/nexus_login_error_after_update_from_1_0_m
ilestone_5_to_1_0_milestone_6

Kamlesh




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Assembly Plugin version 2.4

2012-11-15 Thread Hervé BOUTEMY 
+1

Regards,

Hervé

Le jeudi 15 novembre 2012 00:11:45 Dennis Lundberg a écrit :
 Hi,
 
 We solved 29 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=H
 tmlversion=18308
 
 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11126sta
 tus=1
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-039/
 https://repository.apache.org/content/repositories/maven-039/org/apache/mave
 n/plugins/maven-assembly-plugin/2.4/maven-assembly-plugin-2.4-source-release
 .zip
 
 Staging site (wait for the sync):
 http://maven.apache.org/plugins/maven-assembly-plugin-2.4/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Hervé BOUTEMY 
Le jeudi 15 novembre 2012 08:30:11 Jason van Zyl a écrit :
 On Nov 15, 2012, at 8:18 AM, Olivier Lamy ol...@apache.org wrote:
  Hi,
  Currently logger for all mojos is the DefaultPluginManager logger.
  So it's a bit hard to have filtering per plugin (i.e. only compiler in
  debug etc..)
  
  So I'd like to change that to be able to customize mojo logging.
  My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
  org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
  for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
  to debug.
  
  Makes sense ?
 
 Why not use the standard way of using the class name of the plugin and using
 standard techniques for filtering?
some thoughts (to be added to other valid thgoughts in this thread):
- the class name of the plugin: a plugin doesn't have class a name, only 
*mojos* have a class name (a plugin is a collection of mojos that are the real 
parts executed)
- the standard way of using the class name: yes, this is the standard I 
know, but in Maven, actually, the logger is shared between the mojo and every 
other classes the mojo executes, then we're out of the standard the logger is 
the class name causing the log

then IMHO, Maven in its code has a structure that cannot map to the standard 
logger by classname pattern, or we need some refactoring


  The code to change is here:
  https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/
  apache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
  
  WDYT ?
  
  Thanks
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
  
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 I never make the mistake of arguing with people for whose opinions I have no
 respect.
 
 -- Edward Gibbon

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Logger name for mojo

2012-11-15 Thread Hervé BOUTEMY 
+1 for the idea

other complementary ideas:
- groupId is not really useful, plugins's artifactId is in general sufficient
- I'd add goal name
- dot separator, since this is the classical separator in every java logging 
implementations (due to the classical class name as logger pattern)
- add prefix with something like maven., to separate maven logs from logs 
from other tools (probably organized by full class name)

then my preference would go to

maven.${artifactId}.${goal}

which is a domain specific pattern, not the classical full class name

(FYI, that' not the first time I use such domain specific logger name 
pattern, 
and I never had problems with such decision: yes, that's a bit not 
conventional but respects logging frameworks and is easy to understand)

Regards,

Hervé

Le jeudi 15 novembre 2012 14:18:46 Olivier Lamy a écrit :
 Hi,
 Currently logger for all mojos is the DefaultPluginManager logger.
 So it's a bit hard to have filtering per plugin (i.e. only compiler in
 debug etc..)
 
 So I'd like to change that to be able to customize mojo logging.
 My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
 org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
 for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
 to debug.
 
 Makes sense ?
 
 The code to change is here:
 https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/ap
 ache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
 
 WDYT ?
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 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