maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: [VOTE] Maven 3.1.0
Date Fri, 30 Nov 2012 19:46:57 GMT

On Nov 30, 2012, at 11:15 AM, Stephen Connolly <> wrote:

> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0

If it's in 3.0.4 then you are using Mojo.getLog(), which is probably the ideal case, and this
will work without change in 3.1.0.

> Currently 3.0.4 does not provide either the api or an impl, so I need both
> as a dependency..,

If you want to use SLF4J in 3.0.4 where is doesn't exist then yes. But I would just stick
with Mojo.getLog().

> I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
> and part of the plugin jar (because it makes most sense to scope it there)
> What happens when that runs on 3.1.0?

Can you give me a little plugin that demonstrates? I'm building a bunch of sample plugins
now doing all the weird things we can think of.
> Oh and in my custom slf4j impl I actuall knock all the logging levels down
> by 1, because this tool I am using is too verbose and what it spouts at
> INFO is really DEBUG... So bypassing my impl would be a "bad thing" for
> users

You can control that with the configuration included, we have done that with Sisu to quiet
it down.

After chatting with Ceki I learned that it's not possible once SLF4J starts up to change the
implementation. I don't think this is really a problem, the host system picks the implementation
and that's what's used. So I think this is becoming rather clear that we should probably just
pick the best implementation we can and go with it.

> On Friday, 30 November 2012, Jason van Zyl wrote:
>> For case 2) I would say only fork if your logging is know to interfere
>> with standard SLF4J practices which I think would be rare. But I'll see how
>> easy it is to implement a flag while I'm looking at this in general.
>> On Nov 30, 2012, at 4:20 AM, Stephen Connolly <
>>> 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
>>> 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
>>> 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 <>
>> wrote:
>>>> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl <> wrote:
>>>>> On Nov 29, 2012, at 5:56 PM, Benson Margulies <>
>>>> wrote:
>>>>>>> Currently I'm of the mind that if you make a Maven plugin that
>>>> 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
>>>>>> 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?
>>>> 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
>>>>>> 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



Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven

I never make the mistake of arguing with people for whose opinions I have no respect.

-- Edward Gibbon

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message