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 <[email protected]> wrote: > 2012/11/16 Jason van Zyl <[email protected]>: >> >> 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. >> > 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 >>>> <[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) >> >> >> >> >> > > > > -- > 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]
