I'm going to work on the 3.1.0 release all this week and then I will clean up my Logback implementation for comparison and discussion.
On Nov 19, 2012, at 3:38 AM, Olivier Lamy <[email protected]> wrote: > Hi, > I did the two implementations and it's available for testing: > > * https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info (the > mojo logger name is maven.${groupId}.${goal} (see > simplelogger.properties on how to mark a plugin in debug level) > * > https://github.com/olamy/maven-3/commits/logger-mojo-classname-plus-mdc-for-plugin-info > (the mojo logger is the mojo class name + MDC key maven.pluginInfo > value maven.${groupId}.${goal}) note this version doesn't work very > well with site plugin as the site plugin doesn't reset correctly this > MDC value) > > Then both branches available with log4j2: > * https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info-log4j2 > * > https://github.com/olamy/maven-3/tree/logger-mojo-classname-plus-mdc-for-plugin-info-log4j2 > > To try that: ant (-DskipTests=true) NOTE that this will erase your > current maven installation so take care :-) > > > 2012/11/17 Hervé BOUTEMY <[email protected]>: >> Le samedi 17 novembre 2012 08:33:07 Jason van Zyl a écrit : >>> On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY <[email protected]> wrote: >>>>> Inject the SLF4J logger factory and use that with the underlying >>>>> component >>>>> descriptor's implementation definition which is the class name. >>>> >>>> if we change the code, yes, we can do anything >>> >>> I mean in the plugin manager in this specific case for plugins, not >>> everywhere >> if we only change the logger name put in Mojos, I'm not in favor of using the >> classical classname as the logger name, since actual logger use is shared >> between mojo and other classes, then what seems to be the classical >> convention >> is not >> Having a temporary other logger name is better, to give us time to work on >> more extensive solution >> >>>> and if we want to have the logger as class name (which is a good choice), >>>> we'll need to change a lot of code to be consistent with this convention >>> >>> I think in the vast majority of cases it is injected by @Requirement, >> can you point me to an example, please? I don't see >>> descend from AbstractLogEnabled, >> yes, this one is the most used for Mojos >>> or is set in the plugin manager >> the plugin manager uses AbstractLogEnabled, so that's the same as >> AbstractLogEnabled >> >>> which >>> makes it possible to change the hierarchy in the system without changing >>> much. When I'm finished working on this release I will make an >>> implementation using Logback as a point of disucssion with Olivier's Log4j2 >>> implementation. >> choosing the logger name doesn't have anything to do with choosing the >> logging >> implementation: I'd prefer have the two discussions completely separated >> (BTW, thanks Olivier for working on logging questions that are independant >> from implementation solution, just to continue progress) >> >>>> see the actual pattern found in some plugins where a logger instance is >>>> given from one class to another, like [1] >>>> AFAIK, actually, logger in injected through AbstractLogEnabled class. >>>> >>>> Is there a way to inject a logger or a logger manager into a plexus >>>> component? some example? >>> >>> @Requirement has worked for quite some time, >> can point me to an example, please? >> I'd like to rework plugin-tools code to make better use of logging, and test >> ideas we share, since I don't really know which ideas are just a question of >> my bad knowledge of existing solutions and which ideas are really ideas >> without concrete code >> >>> @Inject also now works with the >>> code in trunk. I believe most other cases are plugins that have their >>> logger set by the plugin manager which we have full access to. >> as said before, plugins then give the logger to other classes for them to do >> log >> >>> >>> At any rate I spent all day yesterday looking at the snapshot bounds issue >>> so I'm going to continue with the list for 3.1.0. >> I'm not in a hurry :) >> >>> I'll participate more in >>> the logging discussion post 3.1.0 with an implementation as an example. >> please don't mix logger name discussion with implementation: it works with >> slf4j-simple, and this is exactly why doing most logging design when we're >> still using slf4j-simple is a good idea. >> The discussion to getting more advanced implementation is for the future >> >>>> If I understand the idea, I still don't know how to do that >>>> >>>> Regards, >>>> >>>> Hervé >>>> >>>> >>>> [1] http://maven.apache.org/plugin-tools/maven-plugin- >>>> plugin/xref/org/apache/maven/plugin/plugin/DescriptorGeneratorMojo.html#78 >>>> >>>>>>> -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/ >>>>>>>> or >>>>>>>> g/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) >>>> >>>> --------------------------------------------------------------------- >>>> 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) >> >> --------------------------------------------------------------------- >> 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] > 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
