maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Graham <chrisgw...@gmail.com>
Subject Re: Logger name for mojo
Date Fri, 16 Nov 2012 23:01:01 GMT
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 <olamy@apache.org> wrote:

> 2012/11/16 Jason van Zyl <jason@tesla.io>:
>> 
>> On Nov 16, 2012, at 7:30 AM, Benson Margulies <bimargulies@gmail.com> wrote:
>> 
>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham <chrisgwarp@gmail.com> 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 <herve.boutemy@free.fr>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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

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


Mime
View raw message