On Dec 6, 2012, at 4:34 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> I'm interested to help working on adding a metadata to enable slf4j > visibility > from a plugin: by default, slf4j is not visible, plugins are expected to use > plugin-api's Log. But if the plugin wants to use core's slf4j, he would be > able to add an annotation in the goal requiring shared core slf4j, then the > plugin descriptor would enable slf4j api import from core. > I sent a mail a while back with how the internals but here are the things you should know: - We export the SLF4J API currently, and we do not export the implementation - The user gets the implementation used by the core through Mojo.getLog(), or by injecting an SLF4J logger - SLF4J once initialized cannot change the implementation so there isn't going to be any deciding by the user to use something else, it's not possible after initialization If you want to try and block the SLF4J API then you'll have to dynamically change what packages get imported into the plugin realm. The ClassRealm manager already gets injected into the plugin manager and you could look at the annotation and alter the the realm created accordingly in DefaultMavenPluginManager.calcImports(). Is this a good idea. I don't really think so but give it a whirl. It means that the logging for the plugin won't be integrated so if someone uses the -l option and the rest of the input goes once place and some plugins go to another. I also don't know what other side effects so I think it would be wise to see what actually happens. One benefit is that it would hopefully fix the Sonar problem. But I'm not sure what the exact behaviour of SLF4J is. Even if a plugin blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar case, I think SLF4J is already loaded. Ceki might want to comment on how that works. If two SLF4J "systems" can run in the same JVM it may work. For the non-SLF4J case it's not using SLF4J, obviously, so there is no need to block it. So if the desire is to allow for a plugin to do its own SLF4J thing you'll want to investigate if it's possible. If it's not then I don't think anything needs to change from how it currently is. If you can make Sonar work, it's worth it the effort. > Stephen: is this what you have in mind? > > Regards, > > Hervé > > Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : >> I tend to agree. There are two use-cases I see that a plugin has for >> bundling a logging implementation: >> >> 1. They are wanting to shunt the logs from the build tool they are invoking >> on to the user. Typically if they are being good plugins they just take the >> logging output and shunt it onto org.apache.maven.plugin.Log.info() >> >> 2. They are wanting to shunt the logs from the build tool (or more likely >> app server) to a separate file, or tweak the level of logs higher than INFO >> for that app server/mojo execution as it will just drown the user. >> >> In the first use case, Jason's point is correct. They shouldn't need to >> bundle a logging implementation any more. >> >> The second case, Jason is arguing that they shouldn't be using the Maven >> JVM for running that tool, they should be running it in a forked JVM and >> then they can configure the logging in that JVM. I disagree. Forking a JVM >> for every little build tool just to control its logging is going to kill >> the build time. >> >> My preference is for a metadata flag that says: Oy! I know what I'm doing >> with logging, so don't pass logging on to me. >> >> While it feels like a "special case" the truth is logging is always, and >> always will be, a special case! >> >> -Stephen >> >> On 30 November 2012 12:09, Benson Margulies <bimargul...@gmail.com> wrote: >>> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl <ja...@tesla.io> wrote: >>>> On Nov 29, 2012, at 5:56 PM, Benson Margulies <bimargul...@gmail.com> >>> >>> wrote: >>>>>> Currently I'm of the mind that if you make a Maven plugin that uses >>> >>> something that employs SLF4J then the best practice is to only use the API >>> and let the host choose the implementation, in our case Maven. Relying on >>> SLF4J implementation specifics in a system you're embedded in is not good >>> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to >>> your own logging thing while being invoked by Maven then you fork the JVM >>> and then you can do whatever you want. >>> >>>>> I read Olivier's point to be this: it would be cool if we could think >>>>> of a way for a plugin to use the slf4j API and remain independent of >>>>> the logging workings of the maven core. >>>> >>>> I think you mean remain independent of the SLF4J implemented used by >>> >>> Maven's core. >>> >>>> Sure, but my counter line of argument would be is that really valid? If >>> >>> you are running in the context of Maven and you're using SLF4J I think you >>> should defer to what Maven has setup. >>> >>>>> As things are, that could be >>>>> done only, I think, by using shade to rename a copy of slf4j for the >>>>> guts of the plugin. >>>> >>>> We have the capability in the core, that is OSGi-esque, that allows us >>> >>> to block classes from being accessible to plugins. We can block/allow any >>> classes we choose: we can effectively make anything invisible to plugins >>> if >>> we choose. This capability was added to Classworlds some time ago. >>> >>>>> If I were less sleep-deprived, I might be able to >>>>> put forth an idea about how an enhancement to slf4j could allow >>>>> everyone to be happy here, but I don't see a way to make everyone >>>>> happy as things are. >>>>> >>>>> My personal view is that 'giant subsystem' plugins are rarities at >>>>> most, and the attraction of saying 'the Maven logging API *is* slf4j' >>>>> outweighs for me the problems. >>>> >>>> I think everyone agrees there, it's really now a matter would we let >>> >>> plugins pick and use a different implementation than the core. >>> >>>>> However, another possibility that occurs to me is this: >>>>> >>>>> Allow a plugin's metadata to say: 'please leave slf4j isolated here'. >>>>> Such a plugin could only log to the Maven log through the Mojo log >>>>> API. >>>> >>>> That's the magic I would like to avoid. Anything is possible but I would >>> >>> prefer how a plugin author should integrate with our SLF4J logging. >>> >>> Here's the crux of the disagreement. To be clear, I'm not trying to >>> derail any 3.1.0 trains here, just thinking ahead. >>> >>> A logging framework is a tool for collecting and distributing >>> information. When someone plugs 'thing X' into Maven, I don't think >>> that it follows, necessarily, that their application of a logging >>> framework necessarily aligns with ours. We are logging 'the build' -- >>> they are logging 'whatever it is that they are doing'. They may log >>> thousands of messages at 'INFO' that are only interesting to some >>> program that digests them, like Apache Flume. That's going to make an >>> awfully hard-to-read console. If we stick to your view, their only >>> option is to mess with the global Maven logging config to reroute >>> their messages, and that's very out of keeping with the whole model of >>> maven plugins as self-contained. >>> >>> I am content to wait for the first JIRA from someone who has this >>> issue, and then advocate for the magic, rather than continue an >>> argument right now. >>> >>>>> I may be understating the strength of Olivier's (and others') desire >>>>> to avoid surprising the authors of plugins that call things that call >>>>> slf4j, though I can see 'surprise' in both directions here in the long >>>>> run. >>>> >>>> Given this is 3.1.0 I believe it's more a matter of documenting how >>> >>> plugin should integrate their logging with Maven's SLF4J system. An app >>> server which may integrate all manner of things works. If you want to >>> integrate with me, this is how you need to do it. >>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> 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 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
