On Nov 16, 2012, at 10:25 AM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/11/16 Jason van Zyl <ja...@tesla.io>:
>>
>> On Nov 16, 2012, at 7:30 AM, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham <chrisgw...@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 ?
>
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
>>>> <herve.bout...@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-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...@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is not worth
knowing.
-- Alan Perlis
