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=1380105&view=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=1380105&r1=1380104&r2=1380105&view=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 @@
>>>>>>>       <groupId>org.sonatype.aether</groupId>
>>>>>>>       
> <artifactId>aether-connector-wagon</artifactId>
>>>>>>>     </dependency>
>>>>>>>  +    <dependency>
>>>>>>>  +      <groupId>org.slf4j</groupId>
>>>>>>>  +      <artifactId>slf4j-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=1380105&r1=1380104&r2=1380105&view=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
>

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

Reply via email to