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 > 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, descend from AbstractLogEnabled, or is set in the plugin manager 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. > 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, @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. 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'll participate more in the logging discussion post 3.1.0 with an implementation as an example. > 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)
