On Nov 16, 2012, at 10:03 AM, Stuart McCulloch <mccu...@gmail.com> 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 <ja...@tesla.io> wrote:
>>
>>>
>>> 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.
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> -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)
>>>
>>>
>>>
>>>
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------
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
