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=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 >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > 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 --------------------------------------------------------- Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
