maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@tesla.io>
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 <stephen.alan.connolly@gmail.com> 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 <
>> stephen.alan.connolly@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.
>>> 
>>> 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 <bimargulies@gmail.com>
>> wrote:
>>> 
>>>> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl <jason@tesla.io> wrote:
>>>>> 
>>>>> On Nov 29, 2012, at 5:56 PM, Benson Margulies <bimargulies@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

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

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

-- Edward Gibbon






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