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. > > >> >> >>+ 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 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 >> >> > >Thanks, > >Jason > >---------------------------------------------------------- >Jason van Zyl >Founder & CTO, Sonatype >Founder, Apache Maven >http://twitter.com/jvanzyl >--------------------------------------------------------- > > >The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, >the search for a superior moral justification for selfishness. > > -- John Kenneth Galbraith > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
