On Sep 10, 2012, at 8:04 AM, Benson Margulies wrote:
> There are people who embed Maven, and they are likely to find it
> congenial that they can make it talk to the logging framework of their
> choice by dropping in slf4j-X as needed. For the ordinary
> command-line, Jason and I and others think
There are people who embed Maven, and they are likely to find it
congenial that they can make it talk to the logging framework of their
choice by dropping in slf4j-X as needed. For the ordinary
command-line, Jason and I and others think that we just pick a
backend, put the appropriate jar into M2_H
Yep lots of people mess this up big time... I should know having ended up
writing my own logging adapter at one point in time...
The only api that came close to offering all the required features was
slf4j... And the missing features were in my view less optimal and largely
driven by the telecoms
wait men,
we speak about maven right? how often do you configure your logs to be
"verbose"?
it is often simply [level] - message
other usages are "advanced" (an user will never activate it - i agree when
you dev you can but dev are not targeted users IMO?)
so for such a simple need whatever fra
Sorry - I should have added - "unless your facade uses LocationAwareLogger
instead of the normal Logger".
Ralph
On Sep 10, 2012, at 9:21 AM, Ralph Goers wrote:
>
> On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote:
>
>>
>>> Absolutely. In light of commit r1380105, the next step is for you
>>>
On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote:
>
>> Absolutely. In light of commit r1380105, the next step is for you
>> (Maven folks) to formulate a policy for swapping out logging
>> back-ends.
>
> Well that is what this is all about. And we have this solution available in
> Maven since
Mark, I hope I did not convey the wrong message in my previous
email. Commit r1380105 provides a backward compatible way for existing
Maven plug-ins to continue using org.codehaus.plexus.Logger. The said
Plexus logger would delegate to org.slf4j.Logger to perform actual
logging. By "a policy for
> Absolutely. In light of commit r1380105, the next step is for you
> (Maven folks) to formulate a policy for swapping out logging
> back-ends.
Well that is what this is all about. And we have this solution available in
Maven since 2004. There is already a logging facade which is widely used:
On Sep 9, 2012 8:08:34 pm, Ralh Goers wrote:
> First, I also would recommend moving from plexus logging to SLF4J.
Cool.
> Mark's concerns with incompatibilities only come about with the log4j
> bridge if you are trying to use APis that the SLF4J bridge hasn't
> implemented. Something being use
> But it would be nice to allow the end user the ability to swap out the
> logging implementation if they want.
Yes, that would be very good. I know there's been questions on the
mailing list how to tweak the logging (don't remember exactly what the
wanted to do). So having something that would m
On Sep 9, 2012, at 11:08 PM, Ralph Goers wrote:
> Jason made a comment in a previous reply that said "Ceki is also a committer,
> and will help us fix anything when necessary so that, again, we can focus on
> Maven and not logging." http://people.apache.org/committer-index.html
> doesn't list
First, I also would recommend moving from plexus logging to SLF4J.
Mark's concerns with incompatibilities only come about with the log4j bridge if
you are trying to use APis that the SLF4J bridge hasn't implemented. Something
being used in a plugin really shouldn't be using those.
Although C
On Sep 9, 2012, at 4:19 PM, Mark Struberg wrote:
> nope, no problem with just slf4j api and logback.
> But that wont give us much benefit over just using plexus.Logger.
> At least I do not see it yet
>
With what I've done you can use plexus.Logger if you like until the end of
time, as can any
On Sun, Sep 9, 2012 at 4:19 PM, Mark Struberg wrote:
> nope, no problem with just slf4j api and logback.
> But that wont give us much benefit over just using plexus.Logger.
> At least I do not see it yet
>
> It would make sense if plugins could add a logging bridge which is used by
> 'their' fram
If a plugin creates a custom classloader inheriting from the tccl you can
get issues with slf4j (because of their singleton)
Le 9 sept. 2012 22:20, "Mark Struberg" a écrit :
> nope, no problem with just slf4j api and logback.
> But that wont give us much benefit over just using plexus.Logger.
> A
nope, no problem with just slf4j api and logback.
But that wont give us much benefit over just using plexus.Logger.
At least I do not see it yet
It would make sense if plugins could add a logging bridge which is used by
'their' framework. But otoh we have already kind of a bridge by grabbing the
Mark,
Here's how SLF4J attempts to make all the framework happy living under the same
roof:
http://www.slf4j.org/legacy.html
On Sep 9, 2012, at 3:34 PM, Mark Struberg wrote:
>
>> No client code changes unless the client wants to change it to take
>> advantage of
>> SLF4J.
>
> It's not the
So this situation is present irrespective of your logging facade unless you
just completely isolate yourself. I'm not in favour of trying to completely
isolate ourselves and not use existing frameworks, and SLF4J has likely
encountered most of the troubling obstacles. You're never going to be a
I join too ;)
IMO mvn doesnt need logback or slf4j at all. If you want to get rid of your
log facade use juli to create a new one (as cxf or owb does). Dont mess the
classpath with slf4j which has its drawbacks too
Le 9 sept. 2012 21:44, "Benson Margulies" a écrit :
> On Sun, Sep 9, 2012 at 3:34
On Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg wrote:
>
>> No client code changes unless the client wants to change it to take
>> advantage of
>> SLF4J.
>
> It's not the classes which change but the classpath does. It might then
> contain clashing classes. That is what I'm afraid of to be honest.
> No client code changes unless the client wants to change it to take advantage
> of
> SLF4J.
It's not the classes which change but the classpath does. It might then contain
clashing classes. That is what I'm afraid of to be honest. Because we do not
have the 'other side' (random plugins and
On Sep 9, 2012, at 3:14 PM, Anders Hammar wrote:
> I'll join. :-)
>
>> 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
>> favor, because it's much more common and popular than plexus.
>
> Me too. And I'm even arguing we should try to switch to slf4j in core.
> Sure, no re
I'll join. :-)
> 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
> favor, because it's much more common and popular than plexus.
Me too. And I'm even arguing we should try to switch to slf4j in core.
Sure, no real technical advantage, but I believe it's easier for other
peo
On Sep 9, 2012, at 2:24 PM, Benson Margulies wrote:
> Again, let's deal with this one thing at a time:
>
> 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
> favor, because it's much more common and popular than plexus.
>
> 2. Picking an slf4j-X to deliver logging to somew
Again, let's deal with this one thing at a time:
1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in
favor, because it's much more common and popular than plexus.
2. Picking an slf4j-X to deliver logging to somewhere. I'm somewhat in
favor of java.util.logging for this, because
I think you're trying to preemptively solve for an issue that we may not have.
I believe that if the right JARs are in the classpath first we will easily be
able to tell running the integration tests for Maven and the integration tests
for all the plugins if there's going to be an issue. I belie
On Sep 9, 2012, at 12:57 PM, Mark Struberg wrote:
> +1
>
> maybe we should first try to clarify what to use slf4j for.
>
> slf4j has 2 'adaptors'
>
> 1.) you can use the slf4j-api as logging facede to log to any logging backend
> you like. Be it log4j, logback, etc. In that case you use the s
> Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what
> components use what logging framework.
Yes, only that this sometimes causes really unfriendly classcast exceptions :/
How can we deal with those? Is there a retry possible? Imo not easily.
Could we scan the plugin cla
Boils down to 1) pick a logging facade and 2) pick a default implementation.
SLF4J is really the de facto standard, used everywhere including 15 projects
here at Apache.
It's unlikely to be surprising to anyone with the changes I've made as it will
appear just like it does now. A bunch of log s
I am completely +1 to introducing slf4j as the official API and
allowing plexus logging to slide, however slowly, into the sunset.
Everyone and his or her cat knows the SLF4J API. That, to me, is a
more than sufficient reason to supplement and eventually replace the
existing logging facade. That mi
On Sep 9, 2012, at 12:38 PM, Mark Struberg wrote:
> sorry, didn't catch this reply earlier.
>
> I see, but then we are back to my original problem. Once you add e.g.
> log4j-slf4j binding then you will get nasty class cast exceptions because
> they are not fully binary compatible. If there is
+1
maybe we should first try to clarify what to use slf4j for.
slf4j has 2 'adaptors'
1.) you can use the slf4j-api as logging facede to log to any logging backend
you like. Be it log4j, logback, etc. In that case you use the slf4j API in your
project
2.) you can use slf4j as 'bridge' to othe
On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg wrote:
> sorry, didn't catch this reply earlier.
>
> I see, but then we are back to my original problem. Once you add e.g.
> log4j-slf4j binding then you will get nasty class cast exceptions because
> they are not fully binary compatible. If there i
sorry, didn't catch this reply earlier.
I see, but then we are back to my original problem. Once you add e.g.
log4j-slf4j binding then you will get nasty class cast exceptions because they
are not fully binary compatible. If there is a log4j.jar in the classpath of
the plugin already then it m
Sorry for brevity
> slf4j
and my response is still the same: those are no technical arguments. I asked
the specific question why we shall wrap one logging facade with another logging
facade. And I still got no answer to this one.
>No client code has to use anything from Guice if they wish not t
On Sep 9, 2012, at 4:17 AM, Mark Struberg wrote:
> Can you again please explain me what the benefit of the SLF4J abstraction
> over the already used plexus.Logger is? Both are just logging facades.
>
But really I think the biggest benefit is that, as far as I know, SLF4J
integrates with every
On Sep 9, 2012, at 8:26 AM, Olivier Lamy wrote:
> 2012/9/9 Mark Struberg :
>> Btw, what do you think about moving the core-classrealm config to a
>> properties file and have them detect dynamically?
>>
>> META-INF/maven/core/core-realm.properties
>>
>> with a list of all packages which shall g
On Sep 9, 2012, at 4:17 AM, Mark Struberg wrote:
> Can you again please explain me what the benefit of the SLF4J abstraction
> over the already used plexus.Logger is? Both are just logging facades.
>
Sure, I can repost the list of benefits I posted a couple days ago:
- Ubiquity. SLF4J may not
You guys pick, it's easy enough to switch. The extensions directory only picks
up new components and binds them first. If you want to flip out the
implementation you need to remove the implementation JAR and swap in the other.
Still not terribly hard, and it would likely be integrators flipping
2012/9/9 Mark Struberg :
> Btw, what do you think about moving the core-classrealm config to a
> properties file and have them detect dynamically?
>
> META-INF/maven/core/core-realm.properties
>
> with a list of all packages which shall get exported as core realm.
> That would allow sonatype and o
Btw, what do you think about moving the core-classrealm config to a properties
file and have them detect dynamically?
META-INF/maven/core/core-realm.properties
with a list of all packages which shall get exported as core realm.
That would allow sonatype and others to just place their stuff into
Can you again please explain me what the benefit of the SLF4J abstraction over
the already used plexus.Logger is? Both are just logging facades.
I mean you can still use whatever bridge underneath plexus.Logger. And
plexus.Logger is exclusively used by Maven, so we have a guarantee to not
intro
Log4j2 have a nice impl of slf4j:
http://logging.apache.org/log4j/2.x/performance.html
Are people able to override with putting an other impl in $M2_HOME/lib/ext ?
2012/9/9 Jason van Zyl :
> To complete this work and unify all the logging under SLF4J can we pick an
> implementation?
>
> I have e
43 matches
Mail list logo
