2012/11/16 Stuart McCulloch <[email protected]>: > 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 <[email protected]> wrote: >> >>> >>> On Nov 16, 2012, at 7:30 AM, Benson Margulies <[email protected]> wrote: >>> >>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham <[email protected]> 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 >>>>> <[email protected]>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: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> 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: [email protected] > For additional commands, e-mail: [email protected] > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
