On Fri, Nov 30, 2012 at 7:20 AM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> 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.

I'd be happier with forking if we had a maven-fork-utils project that
allowed any plugin author, easily, to have as many forks at his or her
place-setting as we see in, say, surefire.


>
> 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

Reply via email to