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]
