subject:"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\/or"

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 
introduce classpath clashes. Also, by just adding slf4j you will still miss all 
the other logging facades, so this is only a quarter of a solution imo.


It has exactly zero benefit over just using plain JUL for example. This can be 
used as purely a facade as well and would at least not create any classpath 
clashes.


Actually while looking at the patch then I see quite a lot stuff I'm not sure 
about


 +import com.google.inject.AbstractModule;
I hope we do NOT use guice natively but only JSR-330 stuff in our business code 
and guice is well hidden in an abstraction, don't we?


 +        imports.put( org.sonatype.inject.*, coreRealm );
Nice, but ... I don't see any code change which touches any org.sonatype class. 

I understand that you like to export sonatype specific stuff you need for you 
company in the container core classpath. But wouldn't it be much better to make 
this configurable like we have done in MAVEN_HOME/bin/m2.conf?


LieGrue,
strub



- Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 5:30 AM
 Subject: 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/]
 
T o complete this work and unify all the logging under SLF4J can we pick an 
 implementation?
 
 I have everything routing through SLF4J so everything using Plexus loggers or 
 SLF4J loggers use the same SLF4J implementation. Even if we pick the simple 
 implementation for now I can completely clean up the CLI and it will simply 
 be a 
 matter of dropping in an implementation JAR. Even the Log4J implementation is 
 only 500k in total. I'm using Logback myself but it really doesn't 
 matter what implementation we pick, I'd just like to pick one and finish the 
 cleanup.
 
 On Sep 8, 2012, at 3:39 AM, Stephen Connolly wrote:
 
  +1 on bump to 3.1
 
  On Friday, 7 September 2012, Anders Hammar wrote:
 
  I know. But there wasn't much visible change in v3.0 either. And 
 I'm
  thinking that it would be easier to communicate a dependency on Maven
  3.1+ than 3.0.5+ if some component utilizes the JSR330 support.
 
  Version numbers are cheap. Why not bump and get some attention? :-)
 
  /Anders
 
  On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl ja...@tesla.io 
 wrote:
  There are no visible user changes, so I don't think so. There 
 aren't
  even any changes to integrators unless they want to use take advantage 
 of
  the changes.
 
  On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote:
 
  Maybe this even should bump the version to v3.1?
 
  /Anders
 
  On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy 
 ol...@apache.org wrote:
  Maybe I miss something but we don't have any associated 
 jira entry for
  reference in release notes neither core it test.
  Do you have a bit of time for that ?
 
  Thanks
  --
  Olivier
  2012/9/3  jvan...@apache.org:
  Author: jvanzyl
  Date: Mon Sep  3 01:07:31 2012
  New Revision: 1380105
 
  URL: 
 http://svn.apache.org/viewvc?rev=1380105view=rev
  Log:
  o Enabled support and discovery of JSR-330 components
 
  o Added Slf4j logger factory to support generic JSR-330 
 logging
 
  o Exported Guice package for components that access 
 Guice (or better
  it's injector) directly
 
  Widen export of Guice packages (not ideal, need to look 
 into ways to
  avoid this)
 
  o use specific exports
 
  o for now we will attempt to hide all of Guice in 
 plugin realms and
  we'll do a bit of testing
 
  closes #3
 
  Added:
 
 
 maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLogger.java
 
 
 maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLoggerFactory.java
  Modified:
    maven/maven-3/trunk/apache-maven/pom.xml
 
 
 maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java
    maven/maven-3/trunk/maven-embedder/pom.xml
 
 
 maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
    maven/maven-3/trunk/pom.xml
 
  Modified: maven/maven-3/trunk/apache-maven/pom.xml
  URL:
 
 http://svn.apache.org/viewvc/maven/maven-3/trunk/apache-maven/pom.xml?rev=1380105r1=1380104r2=1380105view=diff
 
 
 ==
  --- maven/maven-3/trunk/apache-maven/pom.xml (original)
  +++ maven/maven-3/trunk/apache-maven/pom.xml Mon Sep  3 
 01:07:31 2012
  @@ -83,6 +83,10 @@
       groupIdorg.sonatype.aether/groupId
       
 artifactIdaether-connector-wagon/artifactId
     /dependency

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/or

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 the maven 
folder and it would get picked up automatically without having to touch any 
source.

wdyt?

LieGrue,
strub




- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 10:17 AM
 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/]
 
 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 
 introduce classpath clashes. Also, by just adding slf4j you will still miss 
 all 
 the other logging facades, so this is only a quarter of a solution imo.
 
 
 It has exactly zero benefit over just using plain JUL for example. This can 
 be 
 used as purely a facade as well and would at least not create any classpath 
 clashes.
 
 
 Actually while looking at the patch then I see quite a lot stuff I'm not 
 sure about
 
 
  +import com.google.inject.AbstractModule;
 I hope we do NOT use guice natively but only JSR-330 stuff in our business 
 code 
 and guice is well hidden in an abstraction, don't we?
 
 
  +        imports.put( org.sonatype.inject.*, coreRealm );
 Nice, but ... I don't see any code change which touches any org.sonatype 
 class. 
 
 I understand that you like to export sonatype specific stuff you need for you 
 company in the container core classpath. But wouldn't it be much better to 
 make this configurable like we have done in MAVEN_HOME/bin/m2.conf?
 
 
 LieGrue,
 strub
 
 
 
 - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org
  Cc: 
  Sent: Sunday, September 9, 2012 5:30 AM
  Subject: 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/]
 
 T o complete this work and unify all the logging under SLF4J can we pick an 
  implementation?
 
  I have everything routing through SLF4J so everything using Plexus loggers 
 or 
  SLF4J loggers use the same SLF4J implementation. Even if we pick the simple 
 
  implementation for now I can completely clean up the CLI and it will simply 
 be a 
  matter of dropping in an implementation JAR. Even the Log4J implementation 
 is 
  only 500k in total. I'm using Logback myself but it really doesn't 
  matter what implementation we pick, I'd just like to pick one and 
 finish the 
  cleanup.
 
  On Sep 8, 2012, at 3:39 AM, Stephen Connolly wrote:
 
   +1 on bump to 3.1
 
   On Friday, 7 September 2012, Anders Hammar wrote:
 
   I know. But there wasn't much visible change in v3.0 either. 
 And 
  I'm
   thinking that it would be easier to communicate a dependency on 
 Maven
   3.1+ than 3.0.5+ if some component utilizes the JSR330 support.
 
   Version numbers are cheap. Why not bump and get some attention? 
 :-)
 
   /Anders
 
   On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl 
 ja...@tesla.io 
  wrote:
   There are no visible user changes, so I don't think so. 
 There 
  aren't
   even any changes to integrators unless they want to use take 
 advantage 
  of
   the changes.
 
   On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote:
 
   Maybe this even should bump the version to v3.1?
 
   /Anders
 
   On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy 
  ol...@apache.org wrote:
   Maybe I miss something but we don't have any 
 associated 
  jira entry for
   reference in release notes neither core it test.
   Do you have a bit of time for that ?
 
   Thanks
   --
   Olivier
   2012/9/3  jvan...@apache.org:
   Author: jvanzyl
   Date: Mon Sep  3 01:07:31 2012
   New Revision: 1380105
 
   URL: 
  http://svn.apache.org/viewvc?rev=1380105view=rev
   Log:
   o Enabled support and discovery of JSR-330 
 components
 
   o Added Slf4j logger factory to support generic 
 JSR-330 
  logging
 
   o Exported Guice package for components that 
 access 
  Guice (or better
   it's injector) directly
 
   Widen export of Guice packages (not ideal, need to 
 look 
  into ways to
   avoid this)
 
   o use specific exports
 
   o for now we will attempt to hide all of Guice in 
  plugin realms and
   we'll do a bit of testing
 
   closes #3
 
   Added:
 
 
 
 maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLogger.java

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/or

2012-09-09 Thread Olivier Lamy

2012/9/9 Mark Struberg strub...@yahoo.de:
 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 the maven 
 folder and it would get picked up automatically without having to touch any 
 source.

 wdyt?
Agree too.
We need something extensible to avoid such hardcoding
I'd like we avoid someone asking to add com.mycompany


 LieGrue,
 strub




 - Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 10:17 AM
 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/]

 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
 introduce classpath clashes. Also, by just adding slf4j you will still miss 
 all
 the other logging facades, so this is only a quarter of a solution imo.


 It has exactly zero benefit over just using plain JUL for example. This can 
 be
 used as purely a facade as well and would at least not create any classpath
 clashes.


 Actually while looking at the patch then I see quite a lot stuff I'm not
 sure about


  +import com.google.inject.AbstractModule;
 I hope we do NOT use guice natively but only JSR-330 stuff in our business 
 code
 and guice is well hidden in an abstraction, don't we?


  +imports.put( org.sonatype.inject.*, coreRealm );
 Nice, but ... I don't see any code change which touches any org.sonatype
 class.

 I understand that you like to export sonatype specific stuff you need for you
 company in the container core classpath. But wouldn't it be much better to
 make this configurable like we have done in MAVEN_HOME/bin/m2.conf?


 LieGrue,
 strub



 - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Sunday, September 9, 2012 5:30 AM
  Subject: 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/]

 T o complete this work and unify all the logging under SLF4J can we pick an
  implementation?

  I have everything routing through SLF4J so everything using Plexus loggers
 or
  SLF4J loggers use the same SLF4J implementation. Even if we pick the simple

  implementation for now I can completely clean up the CLI and it will simply
 be a
  matter of dropping in an implementation JAR. Even the Log4J implementation
 is
  only 500k in total. I'm using Logback myself but it really doesn't
  matter what implementation we pick, I'd just like to pick one and
 finish the
  cleanup.

  On Sep 8, 2012, at 3:39 AM, Stephen Connolly wrote:

   +1 on bump to 3.1

   On Friday, 7 September 2012, Anders Hammar wrote:

   I know. But there wasn't much visible change in v3.0 either.
 And
  I'm
   thinking that it would be easier to communicate a dependency on
 Maven
   3.1+ than 3.0.5+ if some component utilizes the JSR330 support.

   Version numbers are cheap. Why not bump and get some attention?
 :-)

   /Anders

   On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl
 ja...@tesla.io
  wrote:
   There are no visible user changes, so I don't think so.
 There
  aren't
   even any changes to integrators unless they want to use take
 advantage
  of
   the changes.

   On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote:

   Maybe this even should bump the version to v3.1?

   /Anders

   On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy
  ol...@apache.org wrote:
   Maybe I miss something but we don't have any
 associated
  jira entry for
   reference in release notes neither core it test.
   Do you have a bit of time for that ?

   Thanks
   --
   Olivier
   2012/9/3  jvan...@apache.org:
   Author: jvanzyl
   Date: Mon Sep  3 01:07:31 2012
   New Revision: 1380105

   URL:
  http://svn.apache.org/viewvc?rev=1380105view=rev
   Log:
   o Enabled support and discovery of JSR-330
 components

   o Added Slf4j logger factory to support generic
 JSR-330
  logging

   o Exported Guice package for components that
 access
  Guice (or better
   it's injector) directly

   Widen export of Guice packages (not ideal, need to
 look
  into ways to
   avoid this)

   o use specific exports

   o for now we will attempt to hide all of Guice in
  plugin realms and
   we'll do a bit of testing

   closes #3

   Added:



 maven

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/or

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 the 
implementation to, say, log inside a build server, integrate with another 
application, or integrate with another tool (m2e or Netbeans) so I don't see 
this as particularly odious.

On Sep 9, 2012, at 2:31 AM, Olivier Lamy wrote:

 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 ja...@tesla.io:
 To complete this work and unify all the logging under SLF4J can we pick an 
 implementation?
 
 I have everything routing through SLF4J so everything using Plexus loggers 
 or SLF4J loggers use the same SLF4J implementation. Even if we pick the 
 simple implementation for now I can completely clean up the CLI and it will 
 simply be a matter of dropping in an implementation JAR. Even the Log4J 
 implementation is only 500k in total. I'm using Logback myself but it really 
 doesn't matter what implementation we pick, I'd just like to pick one and 
 finish the cleanup.
 
 On Sep 8, 2012, at 3:39 AM, Stephen Connolly wrote:
 
 +1 on bump to 3.1
 
 On Friday, 7 September 2012, Anders Hammar wrote:
 
 I know. But there wasn't much visible change in v3.0 either. And I'm
 thinking that it would be easier to communicate a dependency on Maven
 3.1+ than 3.0.5+ if some component utilizes the JSR330 support.
 
 Version numbers are cheap. Why not bump and get some attention? :-)
 
 /Anders
 
 On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl ja...@tesla.io wrote:
 There are no visible user changes, so I don't think so. There aren't
 even any changes to integrators unless they want to use take advantage of
 the changes.
 
 On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote:
 
 Maybe this even should bump the version to v3.1?
 
 /Anders
 
 On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy ol...@apache.org wrote:
 Maybe I miss something but we don't have any associated jira entry for
 reference in release notes neither core it test.
 Do you have a bit of time for that ?
 
 Thanks
 --
 Olivier
 2012/9/3  jvan...@apache.org:
 Author: jvanzyl
 Date: Mon Sep  3 01:07:31 2012
 New Revision: 1380105
 
 URL: http://svn.apache.org/viewvc?rev=1380105view=rev
 Log:
 o Enabled support and discovery of JSR-330 components
 
 o Added Slf4j logger factory to support generic JSR-330 logging
 
 o Exported Guice package for components that access Guice (or better
 it's injector) directly
 
 Widen export of Guice packages (not ideal, need to look into ways to
 avoid this)
 
 o use specific exports
 
 o for now we will attempt to hide all of Guice in plugin realms and
 we'll do a bit of testing
 
 closes #3
 
 Added:
 
 maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLogger.java
 
 maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLoggerFactory.java
 Modified:
  maven/maven-3/trunk/apache-maven/pom.xml
 
 maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java
  maven/maven-3/trunk/maven-embedder/pom.xml
 
 maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
  maven/maven-3/trunk/pom.xml
 
 Modified: maven/maven-3/trunk/apache-maven/pom.xml
 URL:
 http://svn.apache.org/viewvc/maven/maven-3/trunk/apache-maven/pom.xml?rev=1380105r1=1380104r2=1380105view=diff
 
 ==
 --- maven/maven-3/trunk/apache-maven/pom.xml (original)
 +++ maven/maven-3/trunk/apache-maven/pom.xml Mon Sep  3 01:07:31 2012
 @@ -83,6 +83,10 @@
 groupIdorg.sonatype.aether/groupId
 artifactIdaether-connector-wagon/artifactId
   /dependency
 +dependency
 +  groupIdorg.slf4j/groupId
 +  artifactIdslf4j-nop/artifactId
 +/dependency
 /dependencies
 
 build
 
 Modified:
 maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java
 URL:
 http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 We know what we are, but know not what we may be.
 
  -- Shakespeare
 
 
 
 
 
 
 
 
 -- 
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 To

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/or

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 be perfect, but I doubt we'll make anything better.
Used by 15 Apache projects already. No one else in the world uses the Plexus
logging facade.
- Changes have been made in Sisu that allow SLF4J logger to be injectable (we
would have to redo this work).
- M2E uses SLF4J successfully and we never had any problems. We also now get
consistency through the most widely used Maven toolchain.
- There are many default implementations to choose from, including log4j. All
the hard work has been done.
- All the bridges function which pretty much allows all the common frameworks
to be utilized with no work on our side. This allows others to use whatever
they like in their components, and we can absorb almost any component that
exists using its.
- If there are integration issues I'm sure Ceki will fix them. If there are
examples of integrations I'd like to see the examples because I've never seen
them personally. I don't really care to develop another logging facade.

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
introduce classpath clashes. Also, by just adding slf4j you will still miss
all the other logging facades, so this is only a quarter of a solution imo.

I have personally seen very few clashes, none in the near term, and the cost of
sorting out these issues and possibly having to work with SLF4J developers
doesn't really warrant trying to use something custom, not currently developed,
and not used by anyone else in the world.

I'm not sure what you mean by a quarter solution. There is a highly used
facade, with a good community with a decent interface, an abundance of
implementations for people to choose from include one here from Apache, it's
well documented, and everything is now routed through it. What do you think is
missing?

It has exactly zero benefit over just using plain JUL for example. This can
be used as purely a facade as well and would at least not create any
classpath clashes.

Other than JUL loggers can be reclaimed by GC along with their configurations
which is horrible IMO.

Actually while looking at the patch then I see quite a lot stuff I'm not sure
about

+import com.google.inject.AbstractModule;
I hope we do NOT use guice natively but only JSR-330 stuff in our business
code and guice is well hidden in an abstraction, don't we?

No client code has to use anything from Guice if they wish not to but providers
are still very handy, and you can't really avoid providing the initial
bindings. We use Sisu which is a layer on top of Guice which we are always
going to use unless you are going to replace every Plexus component that
exists. So we'll be using Sisu and therefore Guice as the implementation
forever. That's the legacy of Plexus.

+imports.put( org.sonatype.inject.*, coreRealm );
Nice, but ... I don't see any code change which touches any org.sonatype
class.

These are Sisu exports and they are actually now at Eclipse. When we update
those will change.

I understand that you like to export sonatype specific stuff you need for you
company in the container core classpath. But wouldn't it be much better to
make this configurable like we have done in MAVEN_HOME/bin/m2.conf?

It's Sisu specific stuff, not anything that Sonatype needs. This is what's in
the package, helper annotations essentially:

https://github.com/sonatype/sisu/tree/master/sisu-inject/containers/guice-bean/guice-bean-binders/src/main/java/org/sonatype/inject

LieGrue,
strub

- Original Message -
From: Jason van Zyl ja...@tesla.io
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Sunday, September 9, 2012 5:30 AM
Subject: 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/]

T o complete this work and unify all the logging under SLF4J can we pick an
implementation?

I have everything routing through SLF4J so everything using Plexus loggers
or
SLF4J loggers use the same SLF4J implementation. Even if we pick the simple
implementation for now I can completely clean up the CLI and it will simply
be a
matter of dropping in an implementation JAR. Even the Log4J implementation
is
only 500k in total. I'm using Logback myself but it really doesn't
matter what implementation we pick, I'd just like to pick one and finish the
cleanup.

On Sep 8, 2012, at 3:39 AM, Stephen Connolly wrote:

+1 on bump to 3.1

On Friday, 7 September 2012, Anders

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/or


On Sep 9, 2012, at 8:26 AM, Olivier Lamy wrote:

 2012/9/9 Mark Struberg strub...@yahoo.de:
 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 the 
 maven folder and it would get picked up automatically without having to 
 touch any source.
 
 wdyt?
 Agree too.
 We need something extensible to avoid such hardcoding
 I'd like we avoid someone asking to add com.mycompany
 

This isn't ever going to be necessary. That package in the exports is a set of 
annotations for Sisu, now at Eclipse so there isn't anything company specific 
in there. It's core framework bits, so I don't think you gain anything by 
making it a configuration as I think you are misinterpreting what it's for.

 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 10:17 AM
 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/]
 
 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
 introduce classpath clashes. Also, by just adding slf4j you will still miss 
 all
 the other logging facades, so this is only a quarter of a solution imo.
 
 
 It has exactly zero benefit over just using plain JUL for example. This can 
 be
 used as purely a facade as well and would at least not create any classpath
 clashes.
 
 
 Actually while looking at the patch then I see quite a lot stuff I'm not
 sure about
 
 
 +import com.google.inject.AbstractModule;
 I hope we do NOT use guice natively but only JSR-330 stuff in our business 
 code
 and guice is well hidden in an abstraction, don't we?
 
 
 +imports.put( org.sonatype.inject.*, coreRealm );
 Nice, but ... I don't see any code change which touches any org.sonatype
 class.
 
 I understand that you like to export sonatype specific stuff you need for 
 you
 company in the container core classpath. But wouldn't it be much better to
 make this configurable like we have done in MAVEN_HOME/bin/m2.conf?
 
 
 LieGrue,
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 5:30 AM
 Subject: 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/]
 
 T o complete this work and unify all the logging under SLF4J can we pick an
 implementation?
 
 I have everything routing through SLF4J so everything using Plexus loggers
 or
 SLF4J loggers use the same SLF4J implementation. Even if we pick the simple
 
 implementation for now I can completely clean up the CLI and it will simply
 be a
 matter of dropping in an implementation JAR. Even the Log4J implementation
 is
 only 500k in total. I'm using Logback myself but it really doesn't
 matter what implementation we pick, I'd just like to pick one and
 finish the
 cleanup.
 
 On Sep 8, 2012, at 3:39 AM, Stephen Connolly wrote:
 
  +1 on bump to 3.1
 
  On Friday, 7 September 2012, Anders Hammar wrote:
 
  I know. But there wasn't much visible change in v3.0 either.
 And
 I'm
  thinking that it would be easier to communicate a dependency on
 Maven
  3.1+ than 3.0.5+ if some component utilizes the JSR330 support.
 
  Version numbers are cheap. Why not bump and get some attention?
 :-)
 
  /Anders
 
  On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl
 ja...@tesla.io
 wrote:
  There are no visible user changes, so I don't think so.
 There
 aren't
  even any changes to integrators unless they want to use take
 advantage
 of
  the changes.
 
  On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote:
 
  Maybe this even should bump the version to v3.1?
 
  /Anders
 
  On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy
 ol...@apache.org wrote:
  Maybe I miss something but we don't have any
 associated
 jira entry for
  reference in release notes neither core it test.
  Do you have a bit of time for that ?
 
  Thanks
  --
  Olivier
  2012/9/3  jvan...@apache.org:
  Author: jvanzyl
  Date: Mon Sep  3 01:07:31 2012
  New Revision: 1380105
 
  URL:
 http://svn.apache.org/viewvc?rev=1380105view=rev
  Log:
  o Enabled support and discovery of JSR-330
 components
 
  o Added Slf4j logger factory to support generic
 JSR-330
 logging

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/or


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 known logging framework right now. In that it can coerce 
JUL, and CL logging into a unified framework which I don't believe any of the 
other frameworks do, or do as well. Maven is about integration and for logging 
I believe it's the best solution that exists for the least effort.

I think it's been adopted at Apache by so many projects specifically for those 
reasons. Ceki is also a committer, and will help us fix anything when necessary 
so that, again, we can focus on Maven and not logging.

Thanks,

Jason

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

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa

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/or

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 to 
but providers 

are still very handy, and you can't really avoid providing the initial 
bindings. 
There are clearly 2 different things 


A.) javax.inject.* which is specified in JSR-330

B.) guice which is just ONE of ten possible implementations of JSR-330

In a plugin I would not use anything else than stuff which is defined in 
JSR-330. So I'm not sure what exposing guice to plugin developers should help.



We use Sisu which is a layer on top of Guice 
which we are always going 

to use unless you are going to replace every 
Plexus component that exists.
So we'll be using Sisu and therefore Guice as the implementation forever. 

That's the legacy of Plexus.

Wrong, wrong, wrong! Hell, Sisu is just a wrapper over the plexus API. You 
could back this with any DI container you like. There is (was) NADA in the 
basic maven structure which needs it to be guice. Archiva even had a plexus 
impl which was backed by Spring _long_ before Sisu even started. All that stuff 
is not new. 


I for my part would like to keep it as portable as possible and only rely on 
standard specced APIs if available.

LieGrue,
strub




 From: Jason van Zyl ja...@tesla.io
To: Maven Developers List dev@maven.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Sunday, September 9, 2012 4:06 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, 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 be perfect, but I doubt we'll make anything better. 
Used by 15 Apache projects already. No one else in the world uses the Plexus 
logging facade.
- Changes have been made in Sisu that allow SLF4J logger to be injectable (we 
would have to redo this work).
- M2E uses SLF4J successfully and we never had any problems. We also now get 
consistency through the most widely used Maven toolchain.
- There are many default implementations to choose from, including log4j. All 
the hard work has been done.
- All the bridges function which pretty much allows all the common frameworks 
to be utilized with no work on our side. This allows others to use whatever 
they like in their components, and we can absorb almost any component that 
exists using its.
- If there are integration issues I'm sure Ceki will fix them. If there are 
examples of integrations I'd like to see the examples because I've never seen 
them personally. I don't really care to develop another logging facade.


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 
introduce classpath clashes. Also, by just adding slf4j you will still miss 
all the other logging facades, so this is only a quarter of a solution imo.



I have personally seen very few clashes, none in the near term, and the cost 
of sorting out these issues and possibly having to work with SLF4J developers 
doesn't really warrant trying to use something custom, not currently 
developed, and not used by anyone else in the world.


I'm not sure what you mean by a quarter solution. There is a highly used 
facade, with a good community with a decent interface, an abundance of 
implementations for people to choose from include one here from Apache, it's 
well documented, and everything is now routed through it. What do you think is 
missing?



It has exactly zero benefit over just using plain JUL for example. This can 
be used as purely a facade as well and would at least not create any 
classpath clashes.




Other than JUL loggers can be reclaimed by GC along with their configurations 
which is horrible IMO.


Actually while looking at the patch then I see quite a lot stuff I'm not sure 
about



+import com.google.inject.AbstractModule;
I hope we do NOT use guice natively but only JSR-330 stuff in our business 
code and guice is well hidden in an abstraction, don't we?



No client code has to use anything from Guice if they wish not to but 
providers are still very handy, and you can't really avoid providing the 
initial bindings. We use Sisu which is a layer on top of Guice which we are 
always going to use unless you are going to replace every Plexus component 
that exists. So we'll be using Sisu and therefore Guice as the implementation 
forever. That's the legacy of Plexus

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/or

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 might even crash with a weird Exception.


I've seen such problems in the wild.
This is nothing which slf4j does wrong - it's just not really possible to do it 
100% right.

We imo only have the option to choose between different kinds of 'broken'.


LieGrue,
strub




- Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: 
 Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it can 
 coerce 
 JUL, and CL logging into a unified framework which I don't believe any of 
 the other frameworks do, or do as well. Maven is about integration and for 
 logging I believe it's the best solution that exists for the least effort.
 
 I think it's been adopted at Apache by so many projects specifically for 
 those reasons. Ceki is also a committer, and will help us fix anything when 
 necessary so that, again, we can focus on Maven and not logging.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Selfish deeds are the shortest path to self destruction.
 
 -- The Seven Samuari, Akira Kurosawa


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@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/or

On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de 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 a log4j.jar in the 
 classpath of the plugin already then it might even crash with a weird 
 Exception.

Folks, I'm sorry, but I'm not following this argument. I apologize for
being slow, but I really wish that someone would sort this into a
small number of questions and explain the pros and cons of them.

I'm fine with declaring SLF4J to be the primary logging API inside
Maven, and leaving it to individual plugin authors to toss in X-slf4j
if they want to. I can see why putting X-slf4j into the plugin
classpath by default could have surprising and unpleasant results, but
there might be a persuasive reason to do it anyway.





 I've seen such problems in the wild.
 This is nothing which slf4j does wrong - it's just not really possible to do 
 it 100% right.

 We imo only have the option to choose between different kinds of 'broken'.


 LieGrue,
 strub




 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc:
 Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it can 
 coerce
 JUL, and CL logging into a unified framework which I don't believe any of
 the other frameworks do, or do as well. Maven is about integration and for
 logging I believe it's the best solution that exists for the least effort.

 I think it's been adopted at Apache by so many projects specifically for
 those reasons. Ceki is also a committer, and will help us fix anything when
 necessary so that, again, we can focus on Maven and not logging.

 Thanks,

 Jason

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

 Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@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/or

+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 other logging frameworks. Your application 
e.g. 'talks' log4j, commons-logging or jul and slf4j provides an implementation 
for (most of, but sadly not all) of the log4j, etc API and bridges it to slf4j. 


Any others I missed?

1.) is perfectly possible but we have a logging facade already in place: 
plexus.Logger. This stuff exists since a long time and is used in all Maven 
APIs. It would be hard to replace this with SLF4J and I personally see no 
technical reason to do so.

2.) What happens if a plugin in your build already has a native log4j.jar, 
commons-logging.jar, etc already in the classpath? In my experience it will 
cause weird class cast exceptions. Which is not what we want. 

If someone explains me that/how 2. works without introducing possible compat 
issues, then I'm +1 for SLF4j as well.

LieGrue,
strub



- Original Message -
 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 6:43 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 Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de 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 a log4j.jar in the classpath of 
 the 
 plugin already then it might even crash with a weird Exception.
 
 Folks, I'm sorry, but I'm not following this argument. I apologize for
 being slow, but I really wish that someone would sort this into a
 small number of questions and explain the pros and cons of them.
 
 I'm fine with declaring SLF4J to be the primary logging API inside
 Maven, and leaving it to individual plugin authors to toss in X-slf4j
 if they want to. I can see why putting X-slf4j into the plugin
 classpath by default could have surprising and unpleasant results, but
 there might be a persuasive reason to do it anyway.
 
 
 
 
 
  I've seen such problems in the wild.
  This is nothing which slf4j does wrong - it's just not really possible 
 to do it 100% right.
 
  We imo only have the option to choose between different kinds of 
 'broken'.
 
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
  Cc:
  Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it can 
 coerce
  JUL, and CL logging into a unified framework which I don't believe 
 any of
  the other frameworks do, or do as well. Maven is about integration and 
 for
  logging I believe it's the best solution that exists for the least 
 effort.
 
  I think it's been adopted at Apache by so many projects 
 specifically for
  those reasons. Ceki is also a committer, and will help us fix anything 
 when
  necessary so that, again, we can focus on Maven and not logging.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  Selfish deeds are the shortest path to self destruction.
 
  -- The Seven Samuari, Akira Kurosawa
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@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/or


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 a log4j.jar in the 
 classpath of the plugin already then it might even crash with a weird 
 Exception.
 
 
 I've seen such problems in the wild.
 This is nothing which slf4j does wrong - it's just not really possible to do 
 it 100% right.
 
 We imo only have the option to choose between different kinds of 'broken'.
 

I wouldn't say broken, but call them integration issues that all APIs and 
frameworks have. I've been using SLF4J for years with various implementation 
and have rarely run into problems. SLF4J with its pervasiveness, support, 
documentation and implementations has the fewest of these integration issues.

 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: 
 Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it can 
 coerce 
 JUL, and CL logging into a unified framework which I don't believe any of 
 the other frameworks do, or do as well. Maven is about integration and for 
 logging I believe it's the best solution that exists for the least effort.
 
 I think it's been adopted at Apache by so many projects specifically for 
 those reasons. Ceki is also a committer, and will help us fix anything when 
 necessary so that, again, we can focus on Maven and not logging.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Selfish deeds are the shortest path to self destruction.
 
 -- The Seven Samuari, Akira Kurosawa
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

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

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition

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/or

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 might not be a 'technical'
justification, but to me it's a very convincing justification.

I do understand the distinction between X-slf4j, sl4j-api, and
slf4j-X. What I'm fuzzy on is whether we're really arguing about
X-slf4j.

On Sun, Sep 9, 2012 at 12:59 PM, Jason van Zyl ja...@tesla.io wrote:

 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 a log4j.jar in the 
 classpath of the plugin already then it might even crash with a weird 
 Exception.


 I've seen such problems in the wild.
 This is nothing which slf4j does wrong - it's just not really possible to do 
 it 100% right.

 We imo only have the option to choose between different kinds of 'broken'.


 I wouldn't say broken, but call them integration issues that all APIs and 
 frameworks have. I've been using SLF4J for years with various implementation 
 and have rarely run into problems. SLF4J with its pervasiveness, support, 
 documentation and implementations has the fewest of these integration issues.


 LieGrue,
 strub




 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc:
 Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it can 
 coerce
 JUL, and CL logging into a unified framework which I don't believe any of
 the other frameworks do, or do as well. Maven is about integration and for
 logging I believe it's the best solution that exists for the least effort.

 I think it's been adopted at Apache by so many projects specifically for
 those reasons. Ceki is also a committer, and will help us fix anything when
 necessary so that, again, we can focus on Maven and not logging.

 Thanks,

 Jason

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

 Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

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

 Our achievements speak for themselves. What we have to keep track
 of are our failures, discouragements and doubts. We tend to forget
 the past difficulties, the many false starts, and the painful
 groping. We see our past achievements as the end result of a
 clean forward thrust, and our present difficulties as
 signs of decline and decay.

  -- Eric Hoffer, Reflections on the Human Condition






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@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/or

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 statement to the console. It's 
unlikely any plugin author is going to care about changing the implementation 
as its running inside Maven. Integrators may want to change the implementation 
to control how components and plugins log but the authors of plugins should not 
have to care.

SLF4J accompanying utilities also help to sequester log output from commons 
logging and JUL into the same funnel. So even if plugin authors are pulling in 
component we could add the adapters and bridges to make this all work nicely. 
So even if something is using commons-logging or JUL under the covers it will 
all come out, ultimately, through SLF4J.

Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what 
components use what logging framework.

On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:

 On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de 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 a log4j.jar in the 
 classpath of the plugin already then it might even crash with a weird 
 Exception.
 
 Folks, I'm sorry, but I'm not following this argument. I apologize for
 being slow, but I really wish that someone would sort this into a
 small number of questions and explain the pros and cons of them.
 
 I'm fine with declaring SLF4J to be the primary logging API inside
 Maven, and leaving it to individual plugin authors to toss in X-slf4j
 if they want to. I can see why putting X-slf4j into the plugin
 classpath by default could have surprising and unpleasant results, but
 there might be a persuasive reason to do it anyway.
 
 
 
 
 
 I've seen such problems in the wild.
 This is nothing which slf4j does wrong - it's just not really possible to do 
 it 100% right.
 
 We imo only have the option to choose between different kinds of 'broken'.
 
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc:
 Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it can 
 coerce
 JUL, and CL logging into a unified framework which I don't believe any of
 the other frameworks do, or do as well. Maven is about integration and for
 logging I believe it's the best solution that exists for the least effort.
 
 I think it's been adopted at Apache by so many projects specifically for
 those reasons. Ceki is also a committer, and will help us fix anything when
 necessary so that, again, we can focus on Maven and not logging.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Selfish deeds are the shortest path to self destruction.
 
 -- The Seven Samuari, Akira Kurosawa
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

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

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

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/or


 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 classpath upfront?
Can a different class lookup strategy in our ClassRealms help?
Don't we care at all and people must exclude log4j et all manually if they like 
to use a new maven version? 


LieGrue
strub



- Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 7:08 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/]
 
 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 statement to the 
 console. 
 It's unlikely any plugin author is going to care about changing the 
 implementation as its running inside Maven. Integrators may want to change 
 the 
 implementation to control how components and plugins log but the authors of 
 plugins should not have to care.
 
 SLF4J accompanying utilities also help to sequester log output from commons 
 logging and JUL into the same funnel. So even if plugin authors are pulling 
 in 
 component we could add the adapters and bridges to make this all work nicely. 
 So 
 even if something is using commons-logging or JUL under the covers it will 
 all 
 come out, ultimately, through SLF4J.
 
 Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what 
 components use what logging framework.
 
 On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:
 
  On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de 
 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 a log4j.jar in the classpath of 
 the 
 plugin already then it might even crash with a weird Exception.
 
  Folks, I'm sorry, but I'm not following this argument. I apologize 
 for
  being slow, but I really wish that someone would sort this into a
  small number of questions and explain the pros and cons of them.
 
  I'm fine with declaring SLF4J to be the primary logging API inside
  Maven, and leaving it to individual plugin authors to toss in X-slf4j
  if they want to. I can see why putting X-slf4j into the plugin
  classpath by default could have surprising and unpleasant results, but
  there might be a persuasive reason to do it anyway.
 
 
 
 
 
  I've seen such problems in the wild.
  This is nothing which slf4j does wrong - it's just not really 
 possible to do it 100% right.
 
  We imo only have the option to choose between different kinds of 
 'broken'.
 
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org; Mark 
 Struberg strub...@yahoo.de
  Cc:
  Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it 
 can coerce
  JUL, and CL logging into a unified framework which I don't 
 believe any of
  the other frameworks do, or do as well. Maven is about integration 
 and for
  logging I believe it's the best solution that exists for the 
 least effort.
 
  I think it's been adopted at Apache by so many projects 
 specifically for
  those reasons. Ceki is also a committer, and will help us fix 
 anything when
  necessary so that, again, we can focus on Maven and not logging.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder  CTO, Sonatype
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  Selfish deeds are the shortest path to self destruction.
 
  -- The Seven Samuari, Akira Kurosawa
 
 
  -
  To unsubscribe, e-mail

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/or


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 slf4j API in 
 your project
 
 2.) you can use slf4j as 'bridge' to other logging frameworks. Your 
 application e.g. 'talks' log4j, commons-logging or jul and slf4j provides an 
 implementation for (most of, but sadly not all) of the log4j, etc API and 
 bridges it to slf4j. 
 
 
 Any others I missed?
 
 1.) is perfectly possible but we have a logging facade already in place: 
 plexus.Logger. This stuff exists since a long time and is used in all Maven 
 APIs. It would be hard to replace this with SLF4J and I personally see no 
 technical reason to do so.
 

I'm not suggesting we refactor any code. The modus operandi is the same as the 
change from Plexus to Guice. No user visible changes and they can take 
advantage of the changes as they see fit.

I have the Plexus logging mechanism delegating to SLF4J. Took me an afternoon 
and now the Plexus Logger Manager delegates to the SLF4J ILoggerFactory. No 
client code needs to change and it shouldn't have to. The Plexus interfaces can 
stay and be used forever. But if users want to take advantage of a well 
documented, de facto standard they can.

 2.) What happens if a plugin in your build already has a native log4j.jar, 
 commons-logging.jar, etc already in the classpath? In my experience it will 
 cause weird class cast exceptions. Which is not what we want. 
 

I have not seen this when frameworks have used existing logging frameworks. 
Provided the appropriate SLF4J JARs get in the classpath first. 

How are you going to avoid these integration issues using your own facade, 
writing your own implementations and creating your own bridges and adapters. 
When the rubber meets the road and you are truly trying to integrate the 
logging systems you're just going to blazing the same trail SLF4J has already. 
Sure you can have a logging facade that actually doesn't integrate with 
anything. Yes, integration is nasty but this is the work I simply do not want 
to do. All we're doing right now is splitting text out on to the console, we 
don't actually integrate with anything at all.

I'm sure Ceki would be happy to explain how it works if you're interested, I'm 
just a happy user and I've had components with all the logging framework and 
I've not had issues.

 If someone explains me that/how 2. works without introducing possible compat 
 issues, then I'm +1 for SLF4j as well.
 
 LieGrue,
 strub
 
 
 
 - Original Message -
 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 6:43 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 Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de 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 a log4j.jar in the classpath of 
 the 
 plugin already then it might even crash with a weird Exception.
 
 Folks, I'm sorry, but I'm not following this argument. I apologize for
 being slow, but I really wish that someone would sort this into a
 small number of questions and explain the pros and cons of them.
 
 I'm fine with declaring SLF4J to be the primary logging API inside
 Maven, and leaving it to individual plugin authors to toss in X-slf4j
 if they want to. I can see why putting X-slf4j into the plugin
 classpath by default could have surprising and unpleasant results, but
 there might be a persuasive reason to do it anyway.
 
 
 
 
 
 I've seen such problems in the wild.
 This is nothing which slf4j does wrong - it's just not really possible 
 to do it 100% right.
 
 We imo only have the option to choose between different kinds of 
 'broken'.
 
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc:
 Sent: Sunday, September 9, 2012 4:22 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, 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

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/or

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 believe the Ceki has 
probably run into every integration scenario imaginable over the last 10 years 
and he'll help us if required.

I have runt into nasty problems where the classpath and classloaders cannot be 
controlled directly from the host system, but this is obviously within our 
purview to control.

On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:

 
 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 classpath upfront?
 Can a different class lookup strategy in our ClassRealms help?
 Don't we care at all and people must exclude log4j et all manually if they 
 like to use a new maven version? 
 
 
 LieGrue
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 7:08 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/]
 
 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 statement to the 
 console. 
 It's unlikely any plugin author is going to care about changing the 
 implementation as its running inside Maven. Integrators may want to change 
 the 
 implementation to control how components and plugins log but the authors of 
 plugins should not have to care.
 
 SLF4J accompanying utilities also help to sequester log output from commons 
 logging and JUL into the same funnel. So even if plugin authors are pulling 
 in 
 component we could add the adapters and bridges to make this all work 
 nicely. So 
 even if something is using commons-logging or JUL under the covers it will 
 all 
 come out, ultimately, through SLF4J.
 
 Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what 
 components use what logging framework.
 
 On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:
 
 On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de 
 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 a log4j.jar in the classpath of 
 the 
 plugin already then it might even crash with a weird Exception.
 
 Folks, I'm sorry, but I'm not following this argument. I apologize 
 for
 being slow, but I really wish that someone would sort this into a
 small number of questions and explain the pros and cons of them.
 
 I'm fine with declaring SLF4J to be the primary logging API inside
 Maven, and leaving it to individual plugin authors to toss in X-slf4j
 if they want to. I can see why putting X-slf4j into the plugin
 classpath by default could have surprising and unpleasant results, but
 there might be a persuasive reason to do it anyway.
 
 
 
 
 
 I've seen such problems in the wild.
 This is nothing which slf4j does wrong - it's just not really 
 possible to do it 100% right.
 
 We imo only have the option to choose between different kinds of 
 'broken'.
 
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark 
 Struberg strub...@yahoo.de
 Cc:
 Sent: Sunday, September 9, 2012 4:22 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, 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 known logging framework right now. In that it 
 can coerce
 JUL, and CL logging into a unified framework which I don't 
 believe any of
 the other frameworks do, or do as well. Maven is about integration 
 and for
 logging I believe it's the best solution that exists for the 
 least effort.
 
 I think it's been adopted

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/or

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 of the baroque classpath
interactions of log4j initialization. But if others prefer log4j or
even something else, OK.

3. Tossing one or more X-slf4j bridges into the default plugin
classpath. If Mark's concerns about surprises have any foundations in
technical reality, this is where they would turn up. I'm doubtful, but
on the other hand, what if we just didn't do this, and left it to
individual plugin authors to do this if, in fact, they wanted mapping
from some other logging API?

It would be good for some others to join this discussion.



On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
 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 
 believe the Ceki has probably run into every integration scenario imaginable 
 over the last 10 years and he'll help us if required.

 I have runt into nasty problems where the classpath and classloaders cannot 
 be controlled directly from the host system, but this is obviously within our 
 purview to control.

 On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:


 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 classpath upfront?
 Can a different class lookup strategy in our ClassRealms help?
 Don't we care at all and people must exclude log4j et all manually if they 
 like to use a new maven version?


 LieGrue
 strub



 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 7:08 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/]

 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 statement to the 
 console.
 It's unlikely any plugin author is going to care about changing the
 implementation as its running inside Maven. Integrators may want to change 
 the
 implementation to control how components and plugins log but the authors of
 plugins should not have to care.

 SLF4J accompanying utilities also help to sequester log output from commons
 logging and JUL into the same funnel. So even if plugin authors are pulling 
 in
 component we could add the adapters and bridges to make this all work 
 nicely. So
 even if something is using commons-logging or JUL under the covers it will 
 all
 come out, ultimately, through SLF4J.

 Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what
 components use what logging framework.

 On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:

 On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de
 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 a log4j.jar in the classpath 
 of the
 plugin already then it might even crash with a weird Exception.

 Folks, I'm sorry, but I'm not following this argument. I apologize
 for
 being slow, but I really wish that someone would sort this into a
 small number of questions and explain the pros and cons of them.

 I'm fine with declaring SLF4J to be the primary logging API inside
 Maven, and leaving it to individual plugin authors to toss in X-slf4j
 if they want to. I can see why putting X-slf4j into the plugin
 classpath by default could have surprising and unpleasant results, but
 there might be a persuasive reason to do it anyway.





 I've seen such problems in the wild.
 This is nothing which slf4j does wrong - it's just not really
 possible to do it 100% right.

 We imo only have the option to choose between different kinds of
 'broken'.


 LieGrue,
 strub




 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org; Mark
 Struberg strub...@yahoo.de
 Cc:
 Sent: Sunday, September 9

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/or


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 somewhere. I'm somewhat in
 favor of java.util.logging for this, because of the baroque classpath
 interactions of log4j initialization. But if others prefer log4j or
 even something else, OK.
 

Yah, it's SLF4J so pick an implementation.

 3. Tossing one or more X-slf4j bridges into the default plugin
 classpath. If Mark's concerns about surprises have any foundations in
 technical reality, this is where they would turn up. I'm doubtful, but
 on the other hand, what if we just didn't do this, and left it to
 individual plugin authors to do this if, in fact, they wanted mapping
 from some other logging API?

I'm not suggesting this. I've routed the Mojo.getLog() through SLF4J so it just 
does what it does now except the backing implementation is the SLF4J 
implementation. If the user wants to use SLF4J and/or @Inject loggers than they 
have to specify the dependency.

No client code changes unless the client wants to change it to take advantage 
of SLF4J.

 
 It would be good for some others to join this discussion.
 
 
 
 On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
 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 
 believe the Ceki has probably run into every integration scenario imaginable 
 over the last 10 years and he'll help us if required.
 
 I have runt into nasty problems where the classpath and classloaders cannot 
 be controlled directly from the host system, but this is obviously within 
 our purview to control.
 
 On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
 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 classpath upfront?
 Can a different class lookup strategy in our ClassRealms help?
 Don't we care at all and people must exclude log4j et all manually if they 
 like to use a new maven version?
 
 
 LieGrue
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 7:08 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/]
 
 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 statement to the 
 console.
 It's unlikely any plugin author is going to care about changing the
 implementation as its running inside Maven. Integrators may want to change 
 the
 implementation to control how components and plugins log but the authors of
 plugins should not have to care.
 
 SLF4J accompanying utilities also help to sequester log output from commons
 logging and JUL into the same funnel. So even if plugin authors are 
 pulling in
 component we could add the adapters and bridges to make this all work 
 nicely. So
 even if something is using commons-logging or JUL under the covers it will 
 all
 come out, ultimately, through SLF4J.
 
 Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what
 components use what logging framework.
 
 On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:
 
 On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de
 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 a log4j.jar in the classpath 
 of the
 plugin already then it might even crash with a weird Exception.
 
 Folks, I'm sorry, but I'm not following this argument. I apologize
 for
 being slow, but I really wish that someone would sort this into a
 small number of questions and explain the pros and cons of them.
 
 I'm fine with declaring SLF4J to be the primary logging API inside
 Maven, and leaving it to individual plugin authors to toss in X-slf4j
 if they want to. I can see why putting X-slf4j into the plugin
 classpath by default could have surprising

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/or

2012-09-09 Thread Anders Hammar

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
people coming in and understanding the code if we don't use old
(deprecated?) APIs.

 2. Picking an slf4j-X to deliver logging to somewhere. I'm somewhat in
 favor of java.util.logging for this, because of the baroque classpath
 interactions of log4j initialization. But if others prefer log4j or
 even something else, OK.

logback would be my pick.

 3. Tossing one or more X-slf4j bridges into the default plugin
 classpath. If Mark's concerns about surprises have any foundations in
 technical reality, this is where they would turn up. I'm doubtful, but
 on the other hand, what if we just didn't do this, and left it to
 individual plugin authors to do this if, in fact, they wanted mapping
 from some other logging API?

Not sure we should add stuff just in case. I mean, which ones should
we pick? I kind of think it should be none or all. But all would be
impossible I think as it would include stuff we haven't heard of
before.

 It would be good for some others to join this discussion.

Thanks for bringing this discussion down to the pace of us slower people!

/Anders




 On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
 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 
 believe the Ceki has probably run into every integration scenario imaginable 
 over the last 10 years and he'll help us if required.

 I have runt into nasty problems where the classpath and classloaders cannot 
 be controlled directly from the host system, but this is obviously within 
 our purview to control.

 On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:


 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 classpath upfront?
 Can a different class lookup strategy in our ClassRealms help?
 Don't we care at all and people must exclude log4j et all manually if they 
 like to use a new maven version?


 LieGrue
 strub



 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 7:08 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/]

 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 statement to the 
 console.
 It's unlikely any plugin author is going to care about changing the
 implementation as its running inside Maven. Integrators may want to change 
 the
 implementation to control how components and plugins log but the authors of
 plugins should not have to care.

 SLF4J accompanying utilities also help to sequester log output from commons
 logging and JUL into the same funnel. So even if plugin authors are 
 pulling in
 component we could add the adapters and bridges to make this all work 
 nicely. So
 even if something is using commons-logging or JUL under the covers it will 
 all
 come out, ultimately, through SLF4J.

 Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what
 components use what logging framework.

 On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:

 On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de
 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 a log4j.jar in the classpath 
 of the
 plugin already then it might even crash with a weird Exception.

 Folks, I'm sorry, but I'm not following this argument. I apologize
 for
 being slow, but I really wish that someone would sort this into a
 small number of questions and explain the pros and cons of them.

 I'm fine with declaring SLF4J to be the primary logging API inside
 Maven, and leaving it to individual plugin authors to toss in X-slf4j
 if they want to. I can see why putting X-slf4j into the plugin
 classpath

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/or


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 real technical advantage, but I believe it's easier for other
 people coming in and understanding the code if we don't use old
 (deprecated?) APIs.
 

Well, we can if we want for additions. But this method doesn't require it. Have 
to live with your baggage. Forever. But that doesn't mean you can't make 
improvements and I think using SLF4J is one of these improvements.

 2. Picking an slf4j-X to deliver logging to somewhere. I'm somewhat in
 favor of java.util.logging for this, because of the baroque classpath
 interactions of log4j initialization. But if others prefer log4j or
 even something else, OK.
 
 logback would be my pick.
 
 3. Tossing one or more X-slf4j bridges into the default plugin
 classpath. If Mark's concerns about surprises have any foundations in
 technical reality, this is where they would turn up. I'm doubtful, but
 on the other hand, what if we just didn't do this, and left it to
 individual plugin authors to do this if, in fact, they wanted mapping
 from some other logging API?
 
 Not sure we should add stuff just in case. I mean, which ones should
 we pick? I kind of think it should be none or all. But all would be
 impossible I think as it would include stuff we haven't heard of
 before.
 
 It would be good for some others to join this discussion.
 
 Thanks for bringing this discussion down to the pace of us slower people!
 
 /Anders
 
 
 
 
 On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
 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 
 believe the Ceki has probably run into every integration scenario 
 imaginable over the last 10 years and he'll help us if required.
 
 I have runt into nasty problems where the classpath and classloaders cannot 
 be controlled directly from the host system, but this is obviously within 
 our purview to control.
 
 On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
 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 classpath upfront?
 Can a different class lookup strategy in our ClassRealms help?
 Don't we care at all and people must exclude log4j et all manually if they 
 like to use a new maven version?
 
 
 LieGrue
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 7:08 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/]
 
 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 statement to the 
 console.
 It's unlikely any plugin author is going to care about changing the
 implementation as its running inside Maven. Integrators may want to 
 change the
 implementation to control how components and plugins log but the authors 
 of
 plugins should not have to care.
 
 SLF4J accompanying utilities also help to sequester log output from 
 commons
 logging and JUL into the same funnel. So even if plugin authors are 
 pulling in
 component we could add the adapters and bridges to make this all work 
 nicely. So
 even if something is using commons-logging or JUL under the covers it 
 will all
 come out, ultimately, through SLF4J.
 
 Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what
 components use what logging framework.
 
 On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:
 
 On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg strub...@yahoo.de
 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 a log4j.jar in the classpath 
 of the
 plugin already then it might even crash with a weird Exception.
 
 Folks, I'm sorry, but I'm not following this argument. I apologize
 for
 being slow, but I really

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/or


 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 projects) under our own control.


LieGrue,
strub



- Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm somewhat in
  favor of java.util.logging for this, because of the baroque classpath
  interactions of log4j initialization. But if others prefer log4j or
  even something else, OK.
 
 
 Yah, it's SLF4J so pick an implementation.
 
  3. Tossing one or more X-slf4j bridges into the default plugin
  classpath. If Mark's concerns about surprises have any foundations in
  technical reality, this is where they would turn up. I'm doubtful, but
  on the other hand, what if we just didn't do this, and left it to
  individual plugin authors to do this if, in fact, they wanted mapping
  from some other logging API?
 
 I'm not suggesting this. I've routed the Mojo.getLog() through SLF4J so 
 it just does what it does now except the backing implementation is the SLF4J 
 implementation. If the user wants to use SLF4J and/or @Inject loggers than 
 they 
 have to specify the dependency.
 
 No client code changes unless the client wants to change it to take advantage 
 of 
 SLF4J.
 
 
  It would be good for some others to join this discussion.
 
 
 
  On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
  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 
 believe the Ceki has probably run into every integration scenario imaginable 
 over the last 10 years and he'll help us if required.
 
  I have runt into nasty problems where the classpath and classloaders 
 cannot be controlled directly from the host system, but this is obviously 
 within 
 our purview to control.
 
  On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
  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 classpath upfront?
  Can a different class lookup strategy in our ClassRealms help?
  Don't we care at all and people must exclude log4j et all 
 manually if they like to use a new maven version?
 
 
  LieGrue
  strub
 
 
 
  - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Sunday, September 9, 2012 7:08 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/]
 
  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 statement 
 to the console.
  It's unlikely any plugin author is going to care about 
 changing the
  implementation as its running inside Maven. Integrators may 
 want to change the
  implementation to control how components and plugins log but 
 the authors of
  plugins should not have to care.
 
  SLF4J accompanying utilities also help to sequester log output 
 from commons
  logging and JUL into the same funnel. So even if plugin authors 
 are pulling in
  component we could add the adapters and bridges to make this 
 all work nicely. So
  even if something is using commons-logging or JUL under the 
 covers it will all
  come out, ultimately, through SLF4J.
 
  Generally I use jul-to-slf4j and jcl-over-slf4j and then I 
 don't care what
  components use what logging framework.
 
  On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote:
 
  On Sun, Sep 9, 2012 at 12:38 PM, Mark

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/or

On Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg strub...@yahoo.de 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. Because we 
 do not have the 'other side' (random plugins and projects) under our own 
 control.

So, to be clear, we are not talking about the bridges *at all*.

Thus, I claim that Mark's concern boils down to the following: Let's
say that we add slf4j-api, slf4j-logback, and logback-whatever to the
classpath. If I am following, you are worried that some plugin author
somewhere is already using logback with a different version and might
get an unpleasant surprise when the version we pick shows up.

I find this scenario hard to credit. However, if it really worried us,
we could shade the back end, and then the only possible means for
trouble would be a plugin that wanted to use an incompatible version.

If that's not what's worrying you, please humor me with a complete,
concrete, example. If it is, can you cite an example of an existing
plugin that would bust?





 LieGrue,
 strub



 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm somewhat in
  favor of java.util.logging for this, because of the baroque classpath
  interactions of log4j initialization. But if others prefer log4j or
  even something else, OK.


 Yah, it's SLF4J so pick an implementation.

  3. Tossing one or more X-slf4j bridges into the default plugin
  classpath. If Mark's concerns about surprises have any foundations in
  technical reality, this is where they would turn up. I'm doubtful, but
  on the other hand, what if we just didn't do this, and left it to
  individual plugin authors to do this if, in fact, they wanted mapping
  from some other logging API?

 I'm not suggesting this. I've routed the Mojo.getLog() through SLF4J so
 it just does what it does now except the backing implementation is the SLF4J
 implementation. If the user wants to use SLF4J and/or @Inject loggers than 
 they
 have to specify the dependency.

 No client code changes unless the client wants to change it to take 
 advantage of
 SLF4J.


  It would be good for some others to join this discussion.



  On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
  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
 believe the Ceki has probably run into every integration scenario imaginable
 over the last 10 years and he'll help us if required.

  I have runt into nasty problems where the classpath and classloaders
 cannot be controlled directly from the host system, but this is obviously 
 within
 our purview to control.

  On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:


  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 classpath upfront?
  Can a different class lookup strategy in our ClassRealms help?
  Don't we care at all and people must exclude log4j et all
 manually if they like to use a new maven version?


  LieGrue
  strub



  - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Sunday, September 9, 2012 7:08 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/]

  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 statement
 to the console.
  It's unlikely any plugin author is going to care about

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/or

2012-09-09 Thread Romain Manni-Bucau

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 bimargul...@gmail.com a écrit :

 On Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg strub...@yahoo.de 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. Because
 we do not have the 'other side' (random plugins and projects) under our own
 control.

 So, to be clear, we are not talking about the bridges *at all*.

 Thus, I claim that Mark's concern boils down to the following: Let's
 say that we add slf4j-api, slf4j-logback, and logback-whatever to the
 classpath. If I am following, you are worried that some plugin author
 somewhere is already using logback with a different version and might
 get an unpleasant surprise when the version we pick shows up.

 I find this scenario hard to credit. However, if it really worried us,
 we could shade the back end, and then the only possible means for
 trouble would be a plugin that wanted to use an incompatible version.

 If that's not what's worrying you, please humor me with a complete,
 concrete, example. If it is, can you cite an example of an existing
 plugin that would bust?



 
 
  LieGrue,
  strub
 
 
 
  - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm somewhat in
   favor of java.util.logging for this, because of the baroque classpath
   interactions of log4j initialization. But if others prefer log4j or
   even something else, OK.
 
 
  Yah, it's SLF4J so pick an implementation.
 
   3. Tossing one or more X-slf4j bridges into the default plugin
   classpath. If Mark's concerns about surprises have any foundations in
   technical reality, this is where they would turn up. I'm doubtful, but
   on the other hand, what if we just didn't do this, and left it to
   individual plugin authors to do this if, in fact, they wanted mapping
   from some other logging API?
 
  I'm not suggesting this. I've routed the Mojo.getLog() through SLF4J so
  it just does what it does now except the backing implementation is the
 SLF4J
  implementation. If the user wants to use SLF4J and/or @Inject loggers
 than they
  have to specify the dependency.
 
  No client code changes unless the client wants to change it to take
 advantage of
  SLF4J.
 
 
   It would be good for some others to join this discussion.
 
 
 
   On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
   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
  believe the Ceki has probably run into every integration scenario
 imaginable
  over the last 10 years and he'll help us if required.
 
   I have runt into nasty problems where the classpath and classloaders
  cannot be controlled directly from the host system, but this is
 obviously within
  our purview to control.
 
   On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
   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 classpath upfront?
   Can a different class lookup strategy in our ClassRealms help?
   Don't we care at all and people must exclude log4j et all
  manually if they like to use a new maven version?
 
 
   LieGrue
   strub
 
 
 
   - Original Message -
   From: Jason van Zyl ja...@tesla.io
   To: Maven Developers List dev@maven.apache.org
   Cc:
   Sent: Sunday, September 9, 2012 7:08 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

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/or

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 able to 
get away from people potentially making incompatible changes that cause clashes 
and exposing implementations but none of these things are insurmountable. Most 
of the popular logging frameworks keep a decent semblance of compatibility. I 
honestly have not run into a logging classpath problem in years.

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 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 projects) under our own 
 control.
 
 
 LieGrue,
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm somewhat in
 favor of java.util.logging for this, because of the baroque classpath
 interactions of log4j initialization. But if others prefer log4j or
 even something else, OK.
 
 
 Yah, it's SLF4J so pick an implementation.
 
 3. Tossing one or more X-slf4j bridges into the default plugin
 classpath. If Mark's concerns about surprises have any foundations in
 technical reality, this is where they would turn up. I'm doubtful, but
 on the other hand, what if we just didn't do this, and left it to
 individual plugin authors to do this if, in fact, they wanted mapping
 from some other logging API?
 
 I'm not suggesting this. I've routed the Mojo.getLog() through SLF4J so 
 it just does what it does now except the backing implementation is the SLF4J 
 implementation. If the user wants to use SLF4J and/or @Inject loggers than 
 they 
 have to specify the dependency.
 
 No client code changes unless the client wants to change it to take 
 advantage of 
 SLF4J.
 
 
 It would be good for some others to join this discussion.
 
 
 
 On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
 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 
 believe the Ceki has probably run into every integration scenario imaginable 
 over the last 10 years and he'll help us if required.
 
 I have runt into nasty problems where the classpath and classloaders 
 cannot be controlled directly from the host system, but this is obviously 
 within 
 our purview to control.
 
 On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
 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 classpath upfront?
 Can a different class lookup strategy in our ClassRealms help?
 Don't we care at all and people must exclude log4j et all 
 manually if they like to use a new maven version?
 
 
 LieGrue
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 7:08 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/]
 
 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 statement 
 to the console.
 It's unlikely any plugin author is going to care about 
 changing the
 implementation as its running inside Maven. Integrators may 
 want to change the
 implementation to control how components and plugins log but 
 the authors

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/or

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 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 projects) under our own 
 control.
 
 
 LieGrue,
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc: 
 Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm somewhat in
 favor of java.util.logging for this, because of the baroque classpath
 interactions of log4j initialization. But if others prefer log4j or
 even something else, OK.
 
 
 Yah, it's SLF4J so pick an implementation.
 
 3. Tossing one or more X-slf4j bridges into the default plugin
 classpath. If Mark's concerns about surprises have any foundations in
 technical reality, this is where they would turn up. I'm doubtful, but
 on the other hand, what if we just didn't do this, and left it to
 individual plugin authors to do this if, in fact, they wanted mapping
 from some other logging API?
 
 I'm not suggesting this. I've routed the Mojo.getLog() through SLF4J so 
 it just does what it does now except the backing implementation is the SLF4J 
 implementation. If the user wants to use SLF4J and/or @Inject loggers than 
 they 
 have to specify the dependency.
 
 No client code changes unless the client wants to change it to take 
 advantage of 
 SLF4J.
 
 
 It would be good for some others to join this discussion.
 
 
 
 On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote:
 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 
 believe the Ceki has probably run into every integration scenario imaginable 
 over the last 10 years and he'll help us if required.
 
 I have runt into nasty problems where the classpath and classloaders 
 cannot be controlled directly from the host system, but this is obviously 
 within 
 our purview to control.
 
 On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
 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 classpath upfront?
 Can a different class lookup strategy in our ClassRealms help?
 Don't we care at all and people must exclude log4j et all 
 manually if they like to use a new maven version?
 
 
 LieGrue
 strub
 
 
 
 - Original Message -
 From: Jason van Zyl ja...@tesla.io
 To: Maven Developers List dev@maven.apache.org
 Cc:
 Sent: Sunday, September 9, 2012 7:08 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/]
 
 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 statement 
 to the console.
 It's unlikely any plugin author is going to care about 
 changing the
 implementation as its running inside Maven. Integrators may 
 want to change the
 implementation to control how components and plugins log but 
 the authors of
 plugins should not have to care.
 
 SLF4J accompanying utilities also help to sequester log output 
 from commons
 logging and JUL into the same funnel. So even if plugin authors 
 are pulling in
 component we could add the adapters and bridges to make this 
 all work nicely. So
 even if something is using commons-logging or JUL under the 
 covers it will all
 come out, ultimately, through SLF4J.
 
 Generally I use jul-to-slf4j and jcl-over-slf4j and then I 
 don't care what

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/or

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 
stdout and redirecting that to the plexus logger.

LieGrue,
strub







- Original Message -
 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: 
 Sent: Sunday, September 9, 2012 9:44 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 Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg strub...@yahoo.de 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. Because 
 we do not have the 'other side' (random plugins and projects) under our 
 own control.
 
 So, to be clear, we are not talking about the bridges *at all*.
 
 Thus, I claim that Mark's concern boils down to the following: Let's
 say that we add slf4j-api, slf4j-logback, and logback-whatever to the
 classpath. If I am following, you are worried that some plugin author
 somewhere is already using logback with a different version and might
 get an unpleasant surprise when the version we pick shows up.
 
 I find this scenario hard to credit. However, if it really worried us,
 we could shade the back end, and then the only possible means for
 trouble would be a plugin that wanted to use an incompatible version.
 
 If that's not what's worrying you, please humor me with a complete,
 concrete, example. If it is, can you cite an example of an existing
 plugin that would bust?
 
 
 
 
 
  LieGrue,
  strub
 
 
 
  - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm 
 somewhat in
   favor of java.util.logging for this, because of the baroque 
 classpath
   interactions of log4j initialization. But if others prefer log4j 
 or
   even something else, OK.
 
 
  Yah, it's SLF4J so pick an implementation.
 
   3. Tossing one or more X-slf4j bridges into the default plugin
   classpath. If Mark's concerns about surprises have any 
 foundations in
   technical reality, this is where they would turn up. I'm 
 doubtful, but
   on the other hand, what if we just didn't do this, and left it 
 to
   individual plugin authors to do this if, in fact, they wanted 
 mapping
   from some other logging API?
 
  I'm not suggesting this. I've routed the Mojo.getLog() through 
 SLF4J so
  it just does what it does now except the backing implementation is the 
 SLF4J
  implementation. If the user wants to use SLF4J and/or @Inject loggers 
 than they
  have to specify the dependency.
 
  No client code changes unless the client wants to change it to take 
 advantage of
  SLF4J.
 
 
   It would be good for some others to join this discussion.
 
 
 
   On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl 
 ja...@tesla.io wrote:
   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
  believe the Ceki has probably run into every integration scenario 
 imaginable
  over the last 10 years and he'll help us if required.
 
   I have runt into nasty problems where the classpath and 
 classloaders
  cannot be controlled directly from the host system, but this is 
 obviously within
  our purview to control.
 
   On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
   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 classpath upfront?
   Can a different class lookup strategy

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/or

2012-09-09 Thread Romain Manni-Bucau

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 strub...@yahoo.de a écrit :

 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 stdout and redirecting that to the plexus logger.

 LieGrue,
 strub







 - Original Message -
  From: Benson Margulies bimargul...@gmail.com
  To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
  Cc:
  Sent: Sunday, September 9, 2012 9:44 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 Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg strub...@yahoo.de 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.
 Because
  we do not have the 'other side' (random plugins and projects) under our
  own control.
 
  So, to be clear, we are not talking about the bridges *at all*.
 
  Thus, I claim that Mark's concern boils down to the following: Let's
  say that we add slf4j-api, slf4j-logback, and logback-whatever to the
  classpath. If I am following, you are worried that some plugin author
  somewhere is already using logback with a different version and might
  get an unpleasant surprise when the version we pick shows up.
 
  I find this scenario hard to credit. However, if it really worried us,
  we could shade the back end, and then the only possible means for
  trouble would be a plugin that wanted to use an incompatible version.
 
  If that's not what's worrying you, please humor me with a complete,
  concrete, example. If it is, can you cite an example of an existing
  plugin that would bust?
 
 
 
 
 
   LieGrue,
   strub
 
 
 
   - Original Message -
   From: Jason van Zyl ja...@tesla.io
   To: Maven Developers List dev@maven.apache.org
   Cc:
   Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm
  somewhat in
favor of java.util.logging for this, because of the baroque
  classpath
interactions of log4j initialization. But if others prefer log4j
  or
even something else, OK.
 
 
   Yah, it's SLF4J so pick an implementation.
 
3. Tossing one or more X-slf4j bridges into the default plugin
classpath. If Mark's concerns about surprises have any
  foundations in
technical reality, this is where they would turn up. I'm
  doubtful, but
on the other hand, what if we just didn't do this, and left it
  to
individual plugin authors to do this if, in fact, they wanted
  mapping
from some other logging API?
 
   I'm not suggesting this. I've routed the Mojo.getLog() through
  SLF4J so
   it just does what it does now except the backing implementation is the
  SLF4J
   implementation. If the user wants to use SLF4J and/or @Inject loggers
  than they
   have to specify the dependency.
 
   No client code changes unless the client wants to change it to take
  advantage of
   SLF4J.
 
 
It would be good for some others to join this discussion.
 
 
 
On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl
  ja...@tesla.io wrote:
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
   believe the Ceki has probably run into every integration scenario
  imaginable
   over the last 10 years and he'll help us if required.
 
I have runt into nasty problems where the classpath and
  classloaders
   cannot be controlled directly from the host system, but this is
  obviously within
   our purview to control.
 
On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:
 
 
Generally I use jul-to-slf4j and jcl-over-slf4j and
  then I
   don't care what
components use what logging

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/or

On Sun, Sep 9, 2012 at 4:19 PM, Mark Struberg strub...@yahoo.de 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' framework. But otoh we have already kind of a bridge by grabbing the 
 stdout and redirecting that to the plexus logger.

Of course plugins can add bridges that mapped in their favorite
framework in Jason's scheme.


 LieGrue,
 strub







 - Original Message -
 From: Benson Margulies bimargul...@gmail.com
 To: Maven Developers List dev@maven.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc:
 Sent: Sunday, September 9, 2012 9:44 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 Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg strub...@yahoo.de 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. Because
 we do not have the 'other side' (random plugins and projects) under our
 own control.

 So, to be clear, we are not talking about the bridges *at all*.

 Thus, I claim that Mark's concern boils down to the following: Let's
 say that we add slf4j-api, slf4j-logback, and logback-whatever to the
 classpath. If I am following, you are worried that some plugin author
 somewhere is already using logback with a different version and might
 get an unpleasant surprise when the version we pick shows up.

 I find this scenario hard to credit. However, if it really worried us,
 we could shade the back end, and then the only possible means for
 trouble would be a plugin that wanted to use an incompatible version.

 If that's not what's worrying you, please humor me with a complete,
 concrete, example. If it is, can you cite an example of an existing
 plugin that would bust?





  LieGrue,
  strub



  - Original Message -
  From: Jason van Zyl ja...@tesla.io
  To: Maven Developers List dev@maven.apache.org
  Cc:
  Sent: Sunday, September 9, 2012 8:43 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, 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 somewhere. I'm
 somewhat in
   favor of java.util.logging for this, because of the baroque
 classpath
   interactions of log4j initialization. But if others prefer log4j
 or
   even something else, OK.


  Yah, it's SLF4J so pick an implementation.

   3. Tossing one or more X-slf4j bridges into the default plugin
   classpath. If Mark's concerns about surprises have any
 foundations in
   technical reality, this is where they would turn up. I'm
 doubtful, but
   on the other hand, what if we just didn't do this, and left it
 to
   individual plugin authors to do this if, in fact, they wanted
 mapping
   from some other logging API?

  I'm not suggesting this. I've routed the Mojo.getLog() through
 SLF4J so
  it just does what it does now except the backing implementation is the
 SLF4J
  implementation. If the user wants to use SLF4J and/or @Inject loggers
 than they
  have to specify the dependency.

  No client code changes unless the client wants to change it to take
 advantage of
  SLF4J.


   It would be good for some others to join this discussion.



   On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl
 ja...@tesla.io wrote:
   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
  believe the Ceki has probably run into every integration scenario
 imaginable
  over the last 10 years and he'll help us if required.

   I have runt into nasty problems where the classpath and
 classloaders
  cannot be controlled directly from the host system, but this is
 obviously within
  our purview to control.

   On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote:


   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

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/or