Re: Logger name for mojo
I'm going to work on the 3.1.0 release all this week and then I will clean up
my Logback implementation for comparison and discussion.
On Nov 19, 2012, at 3:38 AM, Olivier Lamy wrote:
> Hi,
> I did the two implementations and it's available for testing:
>
> * https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info (the
> mojo logger name is maven.${groupId}.${goal} (see
> simplelogger.properties on how to mark a plugin in debug level)
> *
> https://github.com/olamy/maven-3/commits/logger-mojo-classname-plus-mdc-for-plugin-info
> (the mojo logger is the mojo class name + MDC key maven.pluginInfo
> value maven.${groupId}.${goal}) note this version doesn't work very
> well with site plugin as the site plugin doesn't reset correctly this
> MDC value)
>
> Then both branches available with log4j2:
> * https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info-log4j2
> *
> https://github.com/olamy/maven-3/tree/logger-mojo-classname-plus-mdc-for-plugin-info-log4j2
>
> To try that: ant (-DskipTests=true) NOTE that this will erase your
> current maven installation so take care :-)
>
>
> 2012/11/17 Hervé BOUTEMY :
>> Le samedi 17 novembre 2012 08:33:07 Jason van Zyl a écrit :
>>> On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY wrote:
> Inject the SLF4J logger factory and use that with the underlying
> component
> descriptor's implementation definition which is the class name.
if we change the code, yes, we can do anything
>>>
>>> I mean in the plugin manager in this specific case for plugins, not
>>> everywhere
>> if we only change the logger name put in Mojos, I'm not in favor of using the
>> classical classname as the logger name, since actual logger use is shared
>> between mojo and other classes, then what seems to be the classical
>> convention
>> is not
>> Having a temporary other logger name is better, to give us time to work on
>> more extensive solution
>>
and if we want to have the logger as class name (which is a good choice),
we'll need to change a lot of code to be consistent with this convention
>>>
>>> I think in the vast majority of cases it is injected by @Requirement,
>> can you point me to an example, please? I don't see
>>> descend from AbstractLogEnabled,
>> yes, this one is the most used for Mojos
>>> or is set in the plugin manager
>> the plugin manager uses AbstractLogEnabled, so that's the same as
>> AbstractLogEnabled
>>
>>> which
>>> makes it possible to change the hierarchy in the system without changing
>>> much. When I'm finished working on this release I will make an
>>> implementation using Logback as a point of disucssion with Olivier's Log4j2
>>> implementation.
>> choosing the logger name doesn't have anything to do with choosing the
>> logging
>> implementation: I'd prefer have the two discussions completely separated
>> (BTW, thanks Olivier for working on logging questions that are independant
>> from implementation solution, just to continue progress)
>>
see the actual pattern found in some plugins where a logger instance is
given from one class to another, like [1]
AFAIK, actually, logger in injected through AbstractLogEnabled class.
Is there a way to inject a logger or a logger manager into a plexus
component? some example?
>>>
>>> @Requirement has worked for quite some time,
>> can point me to an example, please?
>> I'd like to rework plugin-tools code to make better use of logging, and test
>> ideas we share, since I don't really know which ideas are just a question of
>> my bad knowledge of existing solutions and which ideas are really ideas
>> without concrete code
>>
>>> @Inject also now works with the
>>> code in trunk. I believe most other cases are plugins that have their
>>> logger set by the plugin manager which we have full access to.
>> as said before, plugins then give the logger to other classes for them to do
>> log
>>
>>>
>>> At any rate I spent all day yesterday looking at the snapshot bounds issue
>>> so I'm going to continue with the list for 3.1.0.
>> I'm not in a hurry :)
>>
>>> I'll participate more in
>>> the logging discussion post 3.1.0 with an implementation as an example.
>> please don't mix logger name discussion with implementation: it works with
>> slf4j-simple, and this is exactly why doing most logging design when we're
>> still using slf4j-simple is a good idea.
>> The discussion to getting more advanced implementation is for the future
>>
If I understand the idea, I still don't know how to do that
Regards,
Hervé
[1] http://maven.apache.org/plugin-tools/maven-plugin-
plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78
>>> -Chris
>>>
>>> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
wrote:
+1 for the idea
other complementary ideas:
- groupId is not really useful, plugins's artifactId is in general
sufficient
Re: Logger name for mojo
Hi,
I did the two implementations and it's available for testing:
* https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info (the
mojo logger name is maven.${groupId}.${goal} (see
simplelogger.properties on how to mark a plugin in debug level)
*
https://github.com/olamy/maven-3/commits/logger-mojo-classname-plus-mdc-for-plugin-info
(the mojo logger is the mojo class name + MDC key maven.pluginInfo
value maven.${groupId}.${goal}) note this version doesn't work very
well with site plugin as the site plugin doesn't reset correctly this
MDC value)
Then both branches available with log4j2:
* https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info-log4j2
*
https://github.com/olamy/maven-3/tree/logger-mojo-classname-plus-mdc-for-plugin-info-log4j2
To try that: ant (-DskipTests=true) NOTE that this will erase your
current maven installation so take care :-)
2012/11/17 Hervé BOUTEMY :
> Le samedi 17 novembre 2012 08:33:07 Jason van Zyl a écrit :
>> On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY wrote:
>> >> Inject the SLF4J logger factory and use that with the underlying
>> >> component
>> >> descriptor's implementation definition which is the class name.
>> >
>> > if we change the code, yes, we can do anything
>>
>> I mean in the plugin manager in this specific case for plugins, not
>> everywhere
> if we only change the logger name put in Mojos, I'm not in favor of using the
> classical classname as the logger name, since actual logger use is shared
> between mojo and other classes, then what seems to be the classical convention
> is not
> Having a temporary other logger name is better, to give us time to work on
> more extensive solution
>
>> > and if we want to have the logger as class name (which is a good choice),
>> > we'll need to change a lot of code to be consistent with this convention
>>
>> I think in the vast majority of cases it is injected by @Requirement,
> can you point me to an example, please? I don't see
>> descend from AbstractLogEnabled,
> yes, this one is the most used for Mojos
>> or is set in the plugin manager
> the plugin manager uses AbstractLogEnabled, so that's the same as
> AbstractLogEnabled
>
>> which
>> makes it possible to change the hierarchy in the system without changing
>> much. When I'm finished working on this release I will make an
>> implementation using Logback as a point of disucssion with Olivier's Log4j2
>> implementation.
> choosing the logger name doesn't have anything to do with choosing the logging
> implementation: I'd prefer have the two discussions completely separated
> (BTW, thanks Olivier for working on logging questions that are independant
> from implementation solution, just to continue progress)
>
>> > see the actual pattern found in some plugins where a logger instance is
>> > given from one class to another, like [1]
>> > AFAIK, actually, logger in injected through AbstractLogEnabled class.
>> >
>> > Is there a way to inject a logger or a logger manager into a plexus
>> > component? some example?
>>
>> @Requirement has worked for quite some time,
> can point me to an example, please?
> I'd like to rework plugin-tools code to make better use of logging, and test
> ideas we share, since I don't really know which ideas are just a question of
> my bad knowledge of existing solutions and which ideas are really ideas
> without concrete code
>
>> @Inject also now works with the
>> code in trunk. I believe most other cases are plugins that have their
>> logger set by the plugin manager which we have full access to.
> as said before, plugins then give the logger to other classes for them to do
> log
>
>>
>> At any rate I spent all day yesterday looking at the snapshot bounds issue
>> so I'm going to continue with the list for 3.1.0.
> I'm not in a hurry :)
>
>> I'll participate more in
>> the logging discussion post 3.1.0 with an implementation as an example.
> please don't mix logger name discussion with implementation: it works with
> slf4j-simple, and this is exactly why doing most logging design when we're
> still using slf4j-simple is a good idea.
> The discussion to getting more advanced implementation is for the future
>
>> > If I understand the idea, I still don't know how to do that
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >
>> > [1] http://maven.apache.org/plugin-tools/maven-plugin-
>> > plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78
>> >
>> -Chris
>>
>> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
>> >
>> > wrote:
>> > +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
Re: Logger name for mojo
Le samedi 17 novembre 2012 08:33:07 Jason van Zyl a écrit :
> On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY wrote:
> >> Inject the SLF4J logger factory and use that with the underlying
> >> component
> >> descriptor's implementation definition which is the class name.
> >
> > if we change the code, yes, we can do anything
>
> I mean in the plugin manager in this specific case for plugins, not
> everywhere
if we only change the logger name put in Mojos, I'm not in favor of using the
classical classname as the logger name, since actual logger use is shared
between mojo and other classes, then what seems to be the classical convention
is not
Having a temporary other logger name is better, to give us time to work on
more extensive solution
> > and if we want to have the logger as class name (which is a good choice),
> > we'll need to change a lot of code to be consistent with this convention
>
> I think in the vast majority of cases it is injected by @Requirement,
can you point me to an example, please? I don't see
> descend from AbstractLogEnabled,
yes, this one is the most used for Mojos
> or is set in the plugin manager
the plugin manager uses AbstractLogEnabled, so that's the same as
AbstractLogEnabled
> which
> makes it possible to change the hierarchy in the system without changing
> much. When I'm finished working on this release I will make an
> implementation using Logback as a point of disucssion with Olivier's Log4j2
> implementation.
choosing the logger name doesn't have anything to do with choosing the logging
implementation: I'd prefer have the two discussions completely separated
(BTW, thanks Olivier for working on logging questions that are independant
from implementation solution, just to continue progress)
> > see the actual pattern found in some plugins where a logger instance is
> > given from one class to another, like [1]
> > AFAIK, actually, logger in injected through AbstractLogEnabled class.
> >
> > Is there a way to inject a logger or a logger manager into a plexus
> > component? some example?
>
> @Requirement has worked for quite some time,
can point me to an example, please?
I'd like to rework plugin-tools code to make better use of logging, and test
ideas we share, since I don't really know which ideas are just a question of
my bad knowledge of existing solutions and which ideas are really ideas
without concrete code
> @Inject also now works with the
> code in trunk. I believe most other cases are plugins that have their
> logger set by the plugin manager which we have full access to.
as said before, plugins then give the logger to other classes for them to do
log
>
> At any rate I spent all day yesterday looking at the snapshot bounds issue
> so I'm going to continue with the list for 3.1.0.
I'm not in a hurry :)
> I'll participate more in
> the logging discussion post 3.1.0 with an implementation as an example.
please don't mix logger name discussion with implementation: it works with
slf4j-simple, and this is exactly why doing most logging design when we're
still using slf4j-simple is a good idea.
The discussion to getting more advanced implementation is for the future
> > If I understand the idea, I still don't know how to do that
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] http://maven.apache.org/plugin-tools/maven-plugin-
> > plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78
> >
> -Chris
>
> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
> >
> > wrote:
> > +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
Re: Logger name for mojo
On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY wrote:
>>
>> Inject the SLF4J logger factory and use that with the underlying component
>> descriptor's implementation definition which is the class name.
> if we change the code, yes, we can do anything
I mean in the plugin manager in this specific case for plugins, not everywhere
> and if we want to have the logger as class name (which is a good choice),
> we'll need to change a lot of code to be consistent with this convention
>
I think in the vast majority of cases it is injected by @Requirement, descend
from AbstractLogEnabled, or is set in the plugin manager which makes it
possible to change the hierarchy in the system without changing much. When I'm
finished working on this release I will make an implementation using Logback as
a point of disucssion with Olivier's Log4j2 implementation.
> see the actual pattern found in some plugins where a logger instance is given
> from one class to another, like [1]
> AFAIK, actually, logger in injected through AbstractLogEnabled class.
>
> Is there a way to inject a logger or a logger manager into a plexus component?
> some example?
@Requirement has worked for quite some time, @Inject also now works with the
code in trunk. I believe most other cases are plugins that have their logger
set by the plugin manager which we have full access to.
At any rate I spent all day yesterday looking at the snapshot bounds issue so
I'm going to continue with the list for 3.1.0. I'll participate more in the
logging discussion post 3.1.0 with an implementation as an example.
> If I understand the idea, I still don't know how to do that
>
> Regards,
>
> Hervé
>
>
> [1] http://maven.apache.org/plugin-tools/maven-plugin-
> plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78
>
-Chris
On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
> wrote:
> +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/or
> g/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
>>>
>>> -
>>> 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
>> -
>>
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the separation of the Idea into parts, by dividing it at the joints,
>> as nature directs, not breaking any limb in hal
Re: Logger name for mojo
Le vendredi 16 novembre 2012 09:45:34 Jason van Zyl a écrit :
> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
> > On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham
wrote:
> >> I prefer classname based, as it is, by definition, definative.
> >>
> >> If you're concerned about details getting lost, then might I suggest that
> >> you route that logging output to a separate file? trace.log works for me
> >> (and give a -D to allow users to change that as well).
> >
> > Hervé has pointed out that we already have an API that has no natural
> > mapping to a class name. How would you, or Jason, propose to obtain a
> > class name to go with getLog()?
>
> Inject the SLF4J logger factory and use that with the underlying component
> descriptor's implementation definition which is the class name.
if we change the code, yes, we can do anything
and if we want to have the logger as class name (which is a good choice),
we'll need to change a lot of code to be consistent with this convention
see the actual pattern found in some plugins where a logger instance is given
from one class to another, like [1]
AFAIK, actually, logger in injected through AbstractLogEnabled class.
Is there a way to inject a logger or a logger manager into a plexus component?
some example?
If I understand the idea, I still don't know how to do that
Regards,
Hervé
[1] http://maven.apache.org/plugin-tools/maven-plugin-
plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78
> >> -Chris
> >>
> >> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
wrote:
> >>> +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/or
> >>> g/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
> >
> > -
> > 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
> -
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logger name for mojo
after digging into history of refactoring of this info, I found the revision
that added par and ejb3 packagings [1] and corresponding Jira issue [2]
hope this helps
Regards,
Hervé
[1] http://svn.apache.org/viewvc?view=revision&revision=332151
[2] http://jira.codehaus.org/browse/MNG-699
Le vendredi 16 novembre 2012 10:56:13 Jason van Zyl a écrit :
> On Nov 16, 2012, at 10:03 AM, Stuart McCulloch wrote:
> > On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
> >> And additionally figure what markers might be necessary. So the class
> >> name takes care of any hierarchical filtering, and then you get into
> >> domain specific filtering. Say you instrumented markers across artifact
> >> resolution, or plugin resolution, local repository operations. Many of
> >> the markers could overlap but you might end up with a command line
> >> switch that turns on/off specific domains for debugging or learning
> >> purposes.>
> > Would Mapped Diagnostic Context (MDC) be better than using a marker? This
> > would let you slice the log up by plugin, mojo, etc.
> In parallel mode I suppose you would need MDC to keep things within a thread
> from getting all mucked up. But I still think you would need markers for
> say "artifactResolution", or "buildPlanConstruction", or whatever might
> cross cut the system. And that if there are these known markers people can
> contribute to them in order to have domains they can select to turn on/off.
> We can also do what Olivier is proposing which is to create a marker for a
> particular plugin so that maybe we can help users get very specific. I want
> to see "artifactResolution" within the dependency plugin and that's it. If
> we could do that I believe that would be useful.
> >> On Nov 16, 2012, at 9:45 AM, Jason van Zyl wrote:
> >>> On Nov 16, 2012, at 7:30 AM, Benson Margulies
wrote:
> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham
wrote:
> > I prefer classname based, as it is, by definition, definative.
> >
> > If you're concerned about details getting lost, then might I suggest
> > that
> > you route that logging output to a separate file? trace.log works for
> > me
> > (and give a -D to allow users to change that as well).
>
> Hervé has pointed out that we already have an API that has no natural
> mapping to a class name. How would you, or Jason, propose to obtain a
> class name to go with getLog()?
> >>>
> >>> Inject the SLF4J logger factory and use that with the underlying
> >>> component descriptor's implementation definition which is the class
> >>> name.>>>
> > -Chris
> >
> > On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
wrote:
> >> +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-
Re: Logger name for mojo
To complete the list of Hervé, I was thinking of:
maven [ .$groupId ] .${artifactId} [ [ .${executionId} ] .${goal} ]
Next it would be very nice that if there's an exception during the
process, we could add a line like for instance:
Execute "mvn verify -Lmaven.g.a.e.g=debug" to get extra information of
the failing goal.
Next feature would be to let Maven detect for a goal if it has been
specified with a custom logging level, so it can mark that block by
beginning and ending it with a line of "===" or other character range.
This way users don't have to send complete logs and we don't have to
search for the failing part. For over 90% of the testcases this is enough
info to pinpoint the issue.
-Robert
Op Fri, 16 Nov 2012 07:39:50 +0100 schreef 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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logger name for mojo
I would not over simplify it.
Application tracing is an implicitly complex or verbose means of generating
application execution trace output.
If you're talking about turning on/off specific mojo tracing it is implicitly
technical and a nitty gritty fine tuning operation.
I think it would be a mistake to dumb it down too much.
Additionally, if the tracing options are sufficiently complex (and they will
be) I'd recommend a way of externalizing the trace specification (eg an
eclipse.options file or equivalent).
Just an observation.
-Chris
Sent from my iPhone
On 17/11/2012, at 2:25 AM, Olivier Lamy wrote:
> 2012/11/16 Jason van Zyl :
>>
>> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>>
>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
I prefer classname based, as it is, by definition, definative.
If you're concerned about details getting lost, then might I suggest that
you route that logging output to a separate file? trace.log works for me
(and give a -D to allow users to change that as well).
>>>
>>>
>>>
>>> Hervé has pointed out that we already have an API that has no natural
>>> mapping to a class name. How would you, or Jason, propose to obtain a
>>> class name to go with getLog()?
>>
>> Inject the SLF4J logger factory and use that with the underlying component
>> descriptor's implementation definition which is the class name.
>>
> Technically it's not an issue both are feasible.
> But let's go back to a user perspective.
> What know the user when he use maven?
> He knows he use maven-clean-plugin.goal or tomcat7-maven-plugin.goal
> etc.. he doesn't know classes from org.apache.maven.plugin.clean or
> org.apache.tomcat.maven are executed and we probably don't want.
>
> So if users wants to turn off or activate debug for one or more plugin
> what will be more easy for them ?
>
> And as already proposed we can add a switch in MavenExecutionRequest
> to use one or other mode (as it externals consumers of maven in an
> embeded will be able to choose their prefered mode).
> And we can add too a possible switch tru the cli (maybe tru a sys
> props too to be able to configure that in MAVEN_OPTS).
>
>>>
>>>
>>>
-Chris
On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
wrote:
> +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
>
>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ---
Re: Logger name for mojo
Not that I'd ever ever do this, as the performance would be horrid, but:
In the existing logger impl throw and catch an exception and get the *calling*
class from the stack back trace.
Utterly horrid but it is doable. But is works with all existing plugins and
code with out any refactoring (ie backwards compatible).
I also use this technique when in a mess of interface implementations I get
lost as to whom is calling me. Brute force and ugly, but functional.
-Chris
Sent from my iPhone
On 17/11/2012, at 1:45 AM, Jason van Zyl wrote:
>
> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>
>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>>> I prefer classname based, as it is, by definition, definative.
>>>
>>> If you're concerned about details getting lost, then might I suggest that
>>> you route that logging output to a separate file? trace.log works for me
>>> (and give a -D to allow users to change that as well).
>>
>>
>>
>> Hervé has pointed out that we already have an API that has no natural
>> mapping to a class name. How would you, or Jason, propose to obtain a
>> class name to go with getLog()?
>
> Inject the SLF4J logger factory and use that with the underlying component
> descriptor's implementation definition which is the class name.
>
>>
>>
>>
>>>
>>> -Chris
>>>
>>>
>>> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY wrote:
>>>
+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
>>
>> -
>> 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
> -
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
>
-
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/16 Stuart McCulloch :
> On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
>
>> And additionally figure what markers might be necessary. So the class name
>> takes care of any hierarchical filtering, and then you get into domain
>> specific filtering. Say you instrumented markers across artifact resolution,
>> or plugin resolution, local repository operations. Many of the markers could
>> overlap but you might end up with a command line switch that turns on/off
>> specific domains for debugging or learning purposes.
>
> Would Mapped Diagnostic Context (MDC) be better than using a marker? This
> would let you slice the log up by plugin, mojo, etc.
>
Yup MDC works fine for our case.
I tend to say using Markers will need too much changes as our various
log interfaces (from maven-api our from plexus doesn't accept that) so
that will need a lot of changes.
With MDC we can really add some informations (projectId can help when
using multi threads builds log output)
>> On Nov 16, 2012, at 9:45 AM, Jason van Zyl wrote:
>>
>>>
>>> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>>>
On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
> I prefer classname based, as it is, by definition, definative.
>
> If you're concerned about details getting lost, then might I suggest that
> you route that logging output to a separate file? trace.log works for me
> (and give a -D to allow users to change that as well).
Hervé has pointed out that we already have an API that has no natural
mapping to a class name. How would you, or Jason, propose to obtain a
class name to go with getLog()?
>>>
>>> Inject the SLF4J logger factory and use that with the underlying component
>>> descriptor's implementation definition which is the class name.
>>>
>
> -Chris
>
>
> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
> wrote:
>
>> +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
>>
>>
-
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
>>> -
>>>
>>> First, the taking in of scattered particulars under one Idea,
>>> so that everyone understands what is being talked about ... Second,
>>> th
Re: Logger name for mojo
On Nov 16, 2012, at 10:03 AM, Stuart McCulloch wrote:
> On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
>
>> And additionally figure what markers might be necessary. So the class name
>> takes care of any hierarchical filtering, and then you get into domain
>> specific filtering. Say you instrumented markers across artifact resolution,
>> or plugin resolution, local repository operations. Many of the markers could
>> overlap but you might end up with a command line switch that turns on/off
>> specific domains for debugging or learning purposes.
>
> Would Mapped Diagnostic Context (MDC) be better than using a marker? This
> would let you slice the log up by plugin, mojo, etc.
>
In parallel mode I suppose you would need MDC to keep things within a thread
from getting all mucked up. But I still think you would need markers for say
"artifactResolution", or "buildPlanConstruction", or whatever might cross cut
the system. And that if there are these known markers people can contribute to
them in order to have domains they can select to turn on/off. We can also do
what Olivier is proposing which is to create a marker for a particular plugin
so that maybe we can help users get very specific. I want to see
"artifactResolution" within the dependency plugin and that's it. If we could do
that I believe that would be useful.
>> On Nov 16, 2012, at 9:45 AM, Jason van Zyl wrote:
>>
>>>
>>> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>>>
On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
> I prefer classname based, as it is, by definition, definative.
>
> If you're concerned about details getting lost, then might I suggest that
> you route that logging output to a separate file? trace.log works for me
> (and give a -D to allow users to change that as well).
Hervé has pointed out that we already have an API that has no natural
mapping to a class name. How would you, or Jason, propose to obtain a
class name to go with getLog()?
>>>
>>> Inject the SLF4J logger factory and use that with the underlying component
>>> descriptor's implementation definition which is the class name.
>>>
>
> -Chris
>
>
> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
> wrote:
>
>> +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
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>
Re: Logger name for mojo
On Nov 16, 2012, at 10:25 AM, Olivier Lamy wrote:
> 2012/11/16 Jason van Zyl :
>>
>> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>>
>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
I prefer classname based, as it is, by definition, definative.
If you're concerned about details getting lost, then might I suggest that
you route that logging output to a separate file? trace.log works for me
(and give a -D to allow users to change that as well).
>>>
>>>
>>>
>>> Hervé has pointed out that we already have an API that has no natural
>>> mapping to a class name. How would you, or Jason, propose to obtain a
>>> class name to go with getLog()?
>>
>> Inject the SLF4J logger factory and use that with the underlying component
>> descriptor's implementation definition which is the class name.
>>
> Technically it's not an issue both are feasible.
> But let's go back to a user perspective.
> What know the user when he use maven?
> He knows he use maven-clean-plugin.goal or tomcat7-maven-plugin.goal
> etc.. he doesn't know classes from org.apache.maven.plugin.clean or
> org.apache.tomcat.maven are executed and we probably don't want.
>
> So if users wants to turn off or activate debug for one or more plugin
> what will be more easy for them ?
>
My point was that you shouldn't replace the default mechanism of hierarchy with
the GA. Creating another context with markers or MDC should be used, and that
you should not eradicate the existing norm. So it should be in addition to, not
replacing.
> And as already proposed we can add a switch in MavenExecutionRequest
> to use one or other mode (as it externals consumers of maven in an
> embeded will be able to choose their prefered mode).
> And we can add too a possible switch tru the cli (maybe tru a sys
> props too to be able to configure that in MAVEN_OPTS).
>
>>>
>>>
>>>
-Chris
On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
wrote:
> +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
>
>
>>>
>>> -
>>> 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
>> -
>>
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the
Re: Logger name for mojo
2012/11/16 Jason van Zyl :
>
> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>
>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>>> I prefer classname based, as it is, by definition, definative.
>>>
>>> If you're concerned about details getting lost, then might I suggest that
>>> you route that logging output to a separate file? trace.log works for me
>>> (and give a -D to allow users to change that as well).
>>
>>
>>
>> Hervé has pointed out that we already have an API that has no natural
>> mapping to a class name. How would you, or Jason, propose to obtain a
>> class name to go with getLog()?
>
> Inject the SLF4J logger factory and use that with the underlying component
> descriptor's implementation definition which is the class name.
>
Technically it's not an issue both are feasible.
But let's go back to a user perspective.
What know the user when he use maven?
He knows he use maven-clean-plugin.goal or tomcat7-maven-plugin.goal
etc.. he doesn't know classes from org.apache.maven.plugin.clean or
org.apache.tomcat.maven are executed and we probably don't want.
So if users wants to turn off or activate debug for one or more plugin
what will be more easy for them ?
And as already proposed we can add a switch in MavenExecutionRequest
to use one or other mode (as it externals consumers of maven in an
embeded will be able to choose their prefered mode).
And we can add too a possible switch tru the cli (maybe tru a sys
props too to be able to configure that in MAVEN_OPTS).
>>
>>
>>
>>>
>>> -Chris
>>>
>>>
>>> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY wrote:
>>>
+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
>>
>> -
>> 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
> -
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
>
--
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...@mav
Re: Logger name for mojo
On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
> And additionally figure what markers might be necessary. So the class name
> takes care of any hierarchical filtering, and then you get into domain
> specific filtering. Say you instrumented markers across artifact resolution,
> or plugin resolution, local repository operations. Many of the markers could
> overlap but you might end up with a command line switch that turns on/off
> specific domains for debugging or learning purposes.
Would Mapped Diagnostic Context (MDC) be better than using a marker? This would
let you slice the log up by plugin, mojo, etc.
> On Nov 16, 2012, at 9:45 AM, Jason van Zyl wrote:
>
>>
>> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>>
>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
I prefer classname based, as it is, by definition, definative.
If you're concerned about details getting lost, then might I suggest that
you route that logging output to a separate file? trace.log works for me
(and give a -D to allow users to change that as well).
>>>
>>>
>>>
>>> Hervé has pointed out that we already have an API that has no natural
>>> mapping to a class name. How would you, or Jason, propose to obtain a
>>> class name to go with getLog()?
>>
>> Inject the SLF4J logger factory and use that with the underlying component
>> descriptor's implementation definition which is the class name.
>>
>>>
>>>
>>>
-Chris
On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY
wrote:
> +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
>
>
>>>
>>> -
>>> 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
>> -
>>
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the separation of the Idea into parts, by dividing it at the joints,
>> as nature directs, not breaking any limb in half as a bad carver might.
>>
>> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>>
>>
>>
>>
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
>
Re: Logger name for mojo
And additionally figure what markers might be necessary. So the class name
takes care of any hierarchical filtering, and then you get into domain specific
filtering. Say you instrumented markers across artifact resolution, or plugin
resolution, local repository operations. Many of the markers could overlap but
you might end up with a command line switch that turns on/off specific domains
for debugging or learning purposes.
On Nov 16, 2012, at 9:45 AM, Jason van Zyl wrote:
>
> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>
>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>>> I prefer classname based, as it is, by definition, definative.
>>>
>>> If you're concerned about details getting lost, then might I suggest that
>>> you route that logging output to a separate file? trace.log works for me
>>> (and give a -D to allow users to change that as well).
>>
>>
>>
>> Hervé has pointed out that we already have an API that has no natural
>> mapping to a class name. How would you, or Jason, propose to obtain a
>> class name to go with getLog()?
>
> Inject the SLF4J logger factory and use that with the underlying component
> descriptor's implementation definition which is the class name.
>
>>
>>
>>
>>>
>>> -Chris
>>>
>>>
>>> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY wrote:
>>>
+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
>>
>> -
>> 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
> -
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
>
Thanks,
Jason
--
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Logger name for mojo
On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>> I prefer classname based, as it is, by definition, definative.
>>
>> If you're concerned about details getting lost, then might I suggest that
>> you route that logging output to a separate file? trace.log works for me
>> (and give a -D to allow users to change that as well).
>
>
>
> Hervé has pointed out that we already have an API that has no natural
> mapping to a class name. How would you, or Jason, propose to obtain a
> class name to go with getLog()?
Inject the SLF4J logger factory and use that with the underlying component
descriptor's implementation definition which is the class name.
>
>
>
>>
>> -Chris
>>
>>
>> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY wrote:
>>
>>> +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
>>>
>>>
>
> -
> 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
-
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Logger name for mojo
On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
> I prefer classname based, as it is, by definition, definative.
>
> If you're concerned about details getting lost, then might I suggest that
> you route that logging output to a separate file? trace.log works for me
> (and give a -D to allow users to change that as well).
Hervé has pointed out that we already have an API that has no natural
mapping to a class name. How would you, or Jason, propose to obtain a
class name to go with getLog()?
>
> -Chris
>
>
> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY wrote:
>
>> +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
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logger name for mojo
I prefer classname based, as it is, by definition, definative.
If you're concerned about details getting lost, then might I suggest that
you route that logging output to a separate file? trace.log works for me
(and give a -D to allow users to change that as well).
-Chris
On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY wrote:
> +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
>
>
Re: Logger name for mojo
+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
Re: Logger name for mojo
Le jeudi 15 novembre 2012 08:30:11 Jason van Zyl a écrit :
> On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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
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 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 > wrote: > > > On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl wrote: > >> > >> On Nov 15, 2012, at 11:08 AM, Benson Margulies > 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 > >
Re: Logger name for mojo
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 wrote: > On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl wrote: >> >> On Nov 15, 2012, at 11:08 AM, Benson Margulies 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,
Re: Logger name for mojo
On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl wrote: > > On Nov 15, 2012, at 11:08 AM, Benson Margulies 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 > > --
Re: Logger name for mojo
2012/11/15 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. 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
On Nov 15, 2012, at 11:08 AM, Benson Margulies 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
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
On Nov 15, 2012, at 8:40 AM, Gary Gregory wrote:
> On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>
>>
>> On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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://bit.ly/ECvg0
> Spring Batch in Action: http://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
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 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 wrote:
>> On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>>
>>>
>>> On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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://bit.ly/ECvg0
>> Spring Batch in Action: http://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
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 wrote:
> On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>
>>
>> On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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://bit.ly/ECvg0
> Spring Batch in Action: http://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
On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>
> On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Logger name for mojo
On Nov 15, 2012, at 8:33 AM, Benson Margulies wrote:
> On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>>
>> On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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
On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>
> On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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
On Nov 15, 2012, at 8:18 AM, Olivier Lamy 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
On Thu, Nov 15, 2012 at 8:18 AM, Olivier Lamy 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
Logger name for mojo
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
