You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephane Nicoll <st...@gmail.com> on 2012/08/13 18:24:47 UTC
[RESULT] [VOTE] Maven Shared Filtering 1.1 - Maven Script Interpreter
1.1 - Maven Invoker Plugin 1.7
Hi,
The vote has passed with the following result :
+1 (binding): Olivier Lamy, Stephen Connolly, Mark Struberg, Hervé
Boutemy and Stéphane Nicoll
+1 (non binding): Tony Chemit
I will promote the artifacts to the central repo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by Jason van Zyl <ja...@tesla.io>.
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 that we just pick a
> backend, put the appropriate jar into M2_HOME/lib, and set up a
> reasonable default configuration, suitable tweaked by -X.
>
> Yes, we could do like CXF and have our own -- arguably, we already do,
> with Plexus. (Mark's point, I think.) CXF has particular discontents
> with slf4J related to I18N that Maven has never cared about.
>
> My view is that SLF4J has become so ubiquitous that the number of
> people who will find it congenial will overwhelm the number of people
> who find it inconvenient or problematic.
Yes, I think that's the conclusion that most come to.
I think most of us agree that SLF4J is the best choice for a logging facade.
That said I will finish off my branch to route everything via SLF4J. I will also write up how to swap out the logging implementation but to start I will just put in slf4j-simple. I'm not picky about the implementation because it's easy to change the simple implementation is the closest to the behaviour that's there now.
I just need to sort out how to flip over to a file when that command line option is set and then I'll be finished.
I'll do this tonight.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: SLF4J implementation [was Re: svn commit: r1380105 - in
/maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/
maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by Benson Margulies <bi...@gmail.com>.
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_HOME/lib, and set up a
reasonable default configuration, suitable tweaked by -X.
Yes, we could do like CXF and have our own -- arguably, we already do,
with Plexus. (Mark's point, I think.) CXF has particular discontents
with slf4J related to I18N that Maven has never cared about.
My view is that SLF4J has become so ubiquitous that the number of
people who will find it congenial will overwhelm the number of people
who find it inconvenient or problematic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk:
./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/
maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by ceki <ce...@qos.ch>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in
/maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/
maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 framework you use will be fine no?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/9/10 Ralph Goers <ra...@dslextreme.com>
> 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
> >>> (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!
> >
> > You shouldn't be fine with this. When you wrap SFL4J with a facade you
> will lose all the stack trace info that tells you where your log events are
> being generated as they will all point to the facade instead of the actual
> code doing the logging.
> >
> > Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: SLF4J implementation [was Re: svn commit: r1380105 - in
/maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/
maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by Stephen Connolly <st...@gmail.com>.
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 architect's policy doc... I18nized logs for info and
higher is a bit nuts... And can kill perf (as you need the ability to
reorder the positional params which slf4j's performance impl prevents)
Mark I humbly think you are arguing in a hole... But feel free to enlighten
me with a good reason
On Monday, 10 September 2012, Ralph Goers wrote:
> 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
> >>> (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!
> >
> > You shouldn't be fine with this. When you wrap SFL4J with a facade you
> will lose all the stack trace info that tells you where your log events are
> being generated as they will all point to the facade instead of the actual
> code doing the logging.
> >
> > Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by Ralph Goers <ra...@dslextreme.com>.
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
>>> (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!
>
> You shouldn't be fine with this. When you wrap SFL4J with a facade you will lose all the stack trace info that tells you where your log events are being generated as they will all point to the facade instead of the actual code doing the logging.
>
> Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by Ralph Goers <ra...@dslextreme.com>.
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 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!
You shouldn't be fine with this. When you wrap SFL4J with a facade you will lose all the stack trace info that tells you where your log events are being generated as they will all point to the facade instead of the actual code doing the logging.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by Mark Struberg <st...@yahoo.de>.
> 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!
LieGrue,
strub
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).
----- Original Message -----
> From: ceki <ce...@qos.ch>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Monday, September 10, 2012 12:39 PM
> Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/]
>
> 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 used in a plugin really shouldn't be
>> using those.
>
> Exactly.
>
>> Although Ceki is generally careful not to break compatibility, it has
>> happened. For example, you cannot mix applications that use SLF4J
>> 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much
>> tied to the SLF4J version. See http://www.slf4j.org/news.html. If
>> core is using SLF4J and an incompatible change is made again it
>> probably won't be that big of a deal. Typically, when compatibility
>> has been broken it really hasn't impacted code that uses the SLF4J
>> API.
>
> SLF4J's user facing API, that is classes or interfaces located in the
> org.slf4j package such as Logger, Marker, MDC and LoggerFactory have
> been there and remain unchanged since day one (2005). Thus, a user
> never has to worry about with which version of slf4j-api a dependency
> was compiled with. A user can pick any version of slf4j-api-api.jar
> and as long as the version of the binding of her choice matches, slf4j
> will function correctly. See also [1,2].
>
> The internal interfaces, those in the org.slf4j.spi or
> org.slf4j.helpers packages, may change incompatibly. One of the most
> notable occasions was in the 1.6.0 release when the
> LocationAwareLogger interface was changed. It was done so in response
> to a bug report [3] filed by... Ralph. The reader will appreciate the
> irony.
>
> More objectively though, Ralph filed a valid bug report and the only
> way to fix it was by making an incompatible change in an *internal*
> interface. Unfortunately, given the ubiquity of SLF4J, such
> incompatible changes somehow manage to leak into user-space and annoy
> the hell out of many developers. SLF4J is designed so that the
> problems occurring when deploying SLF4J are obvious with obvious
> solutions -- SLF4J is stupid by design. (Feel free to quote.)
>
>> Mark mentioned shading as a way to "fix" any problems with SLF4J
>> conflicts. I am not sure if shading will work with SLF4J.
>> Implementations must provide a class named
>> org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder
>> and org.slf4j.impl.StaticMDCBinder.
>>
>> 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 him as a
>> committer on Maven and Ceki has said publicly and privately that he is
>> unlikely to contribute to ASF projects. However, while the statement
>> is incorrect I don't understand why what Ceki would or wouldn't do
>> would have any bearing on whether Maven adopts SLF4J.
>
> If need be, I'll happily answer questions and guide you through the
> process of migrating to SLF4J. However, I agree with Ralph, my person
> should have no bearing to whether Maven adopts SLF4J or not.
>
>> Finally, I've been working on Log4j 2 for over 3 years now. The reason
>> I started working on it was due to deficiencies in Logback that occur
>> in large scale web applications and probably don't matter in something
>> like Maven. But it would be nice to allow the end user the ability to
>> swap out the logging implementation if they want.
>
> Absolutely. In light of commit r1380105, the next step is for you
> (Maven folks) to formulate a policy for swapping out logging
> back-ends. In my not so humble opinion, all other questions are moot
> if you don't have a working policy for swapping-in/swapping-out
> logging frameworks. Lacking the necessary knowledge about how Maven
> bootstraps itself or how it manages its classloaders, I am not in a
> position to formulate such policy. On the other hand, there is more
> than enough expert knowledge here to address this problem. I intend to
> follow your future discussions with interest.
>
> [1] http://www.slf4j.org/manual.html#compatibility
> [2] http://www.slf4j.org/codes.html#version_mismatch
> [3] http://bugzilla.slf4j.org/show_bug.cgi?id=127
>
> -- Ceki
> http://tinyurl.com/proLogback
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk:
./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/
maven-embedder/src/main/java/org/apache/maven/cli/]
Posted by ceki <ce...@qos.ch>.
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 used in a plugin really shouldn't be
> using those.
Exactly.
> Although Ceki is generally careful not to break compatibility, it has
> happened. For example, you cannot mix applications that use SLF4J
> 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much
> tied to the SLF4J version. See http://www.slf4j.org/news.html. If
> core is using SLF4J and an incompatible change is made again it
> probably won't be that big of a deal. Typically, when compatibility
> has been broken it really hasn't impacted code that uses the SLF4J
> API.
SLF4J's user facing API, that is classes or interfaces located in the
org.slf4j package such as Logger, Marker, MDC and LoggerFactory have
been there and remain unchanged since day one (2005). Thus, a user
never has to worry about with which version of slf4j-api a dependency
was compiled with. A user can pick any version of slf4j-api-api.jar
and as long as the version of the binding of her choice matches, slf4j
will function correctly. See also [1,2].
The internal interfaces, those in the org.slf4j.spi or
org.slf4j.helpers packages, may change incompatibly. One of the most
notable occasions was in the 1.6.0 release when the
LocationAwareLogger interface was changed. It was done so in response
to a bug report [3] filed by... Ralph. The reader will appreciate the
irony.
More objectively though, Ralph filed a valid bug report and the only
way to fix it was by making an incompatible change in an *internal*
interface. Unfortunately, given the ubiquity of SLF4J, such
incompatible changes somehow manage to leak into user-space and annoy
the hell out of many developers. SLF4J is designed so that the
problems occurring when deploying SLF4J are obvious with obvious
solutions -- SLF4J is stupid by design. (Feel free to quote.)
> Mark mentioned shading as a way to "fix" any problems with SLF4J
> conflicts. I am not sure if shading will work with SLF4J.
> Implementations must provide a class named
> org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder
> and org.slf4j.impl.StaticMDCBinder.
>
> 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 him as a
> committer on Maven and Ceki has said publicly and privately that he is
> unlikely to contribute to ASF projects. However, while the statement
> is incorrect I don't understand why what Ceki would or wouldn't do
> would have any bearing on whether Maven adopts SLF4J.
If need be, I'll happily answer questions and guide you through the
process of migrating to SLF4J. However, I agree with Ralph, my person
should have no bearing to whether Maven adopts SLF4J or not.
> Finally, I've been working on Log4j 2 for over 3 years now. The reason
> I started working on it was due to deficiencies in Logback that occur
> in large scale web applications and probably don't matter in something
> like Maven. But it would be nice to allow the end user the ability to
> swap out the logging implementation if they want.
Absolutely. In light of commit r1380105, the next step is for you
(Maven folks) to formulate a policy for swapping out logging
back-ends. In my not so humble opinion, all other questions are moot
if you don't have a working policy for swapping-in/swapping-out
logging frameworks. Lacking the necessary knowledge about how Maven
bootstraps itself or how it manages its classloaders, I am not in a
position to formulate such policy. On the other hand, there is more
than enough expert knowledge here to address this problem. I intend to
follow your future discussions with interest.
[1] http://www.slf4j.org/manual.html#compatibility
[2] http://www.slf4j.org/codes.html#version_mismatch
[3] http://bugzilla.slf4j.org/show_bug.cgi?id=127
--
Ceki
http://tinyurl.com/proLogback
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org