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 swapping out logging back-ends", I meant
formulating a policy leveraging SLF4J's own binding mechanism within
Maven.
For the purposes of this discussion), if slf4j-simple.jar is the
default logging back-end in Maven, Maven's logging pluggability policy
for switching to j.u.l. could be as straightforward as removing
slf4j-simple.jar from $MAVEN_HOME/lib and replacing it with
slf4j-jul.jar in $MAVEN_HOME/lib. Switching to log4j would entail
replacing slf4j-jul.jar with slf4j-log4j12.jar and log4j.jar in
$MAVEN_HOME/lib. Switching logback would mean replacing
slf4j-log4j12.jar and log4j.jar with logback-core.jar and
logback-classic.jar in $MAVEN_HOME/lib. You get the idea.
As mentioned in my previous message, I don't know if the above would
work due to my ignorance of exactly how Maven bootstraps.
As for exporting SLF4J to Maven plug-ins, you are correct to observe
that this would tie Maven to the SLF4J API. In my undeniably biased
view, attempts at mitigating such coupling invariably yield poor
results. Please see for further discussion.
http://www.slf4j.org/faq.html#optional_dependency
http://tinyurl.com/soWrapping
On 10.09.2012 13:06, 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 2004. There is already a logging facade which
> is widely used: org.codehaus.plexus.Logger
>
> This is used in whole Maven including all plugins which exist. All
> Maven messages get routed through it. I just see no reason for
> swapping out A1 for A2. At least not if A1 is working for years and
> all the Maven APIs are using it. I'm talking about >100 API signatures
> we would need to change in an incompatible way sooner or later!
>
> I'm perfectly fine to back the plexus.Logger facade with SLF4J as
> default impl, but please let's not get this into our API or export it
> to users!
>
> PS: there is a _huge_ difference whether you like to use a logging
> framework in a container or in an end-user application. In a container
> you just don't know what the user will throw into your container. And
> we did tried SLF4J for containers a few times and did hit those
> fundamental problems pretty early on. I'm pretty sure you know exactly
> what I mean. Others can grab the MyFaces, tomcat, OpenWebBeans,
> OpenJPA, ... lists for more info. Most time we either ended up doing
> our own logging facade or used JUL (yea it sucks big times, but at
> least it doesn't create classpath conflicts).
--
Ceki
http://tinyurl.com/proLogback
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
