Re: JSR330 Support
It's up now. The last build with these changes failed though, but it's when jaring one of the modules. I can't trigger a manual build so I can't tell if it was a hiccup or what. /Anders On Mon, Sep 3, 2012 at 3:13 AM, Jason van Zyl ja...@tesla.io wrote: I just committed support for JSR330 components in extensions and plugins. It's building fine on my CI machine and the ITs work, and I'm trying on the official grid but builds.apache.org appears to be down[1]. I'll check in the morning, but if there are any problems feel free to roll back. I can't tell at the moment. [1]: http://www.downforeveryoneorjustme.com/builds.apache.org 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: 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/
whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java (original) +++ maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java Mon Sep 3 01:07:31 2012 @@ -198,6 +198,26 @@ public class DefaultClassRealmManager imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParser, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParserException, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlSerializer, coreRealm ); + + // javax.inject, sisu-inject (JSR-330) + imports.put( javax.inject.*, coreRealm ); + imports.put( javax.enterprise.inject.*, coreRealm ); + imports.put( org.sonatype.inject.*, coreRealm ); + imports.put( org.slf4j.*, coreRealm ); + + // com.google + // + // We may potentially want to export these, but right now I'm not sure that anything Guice specific needs + // to be made available to plugin authors. If we find people are getting fancy and want to take advantage + // of Guice specifics we can expose that later. Really some testing needs to be done to see full hiding + // of Guice has any impact on what we may categorize as a standard JSR-330 based Tesla/Maven plugin. + // + // imports.put( com.google.inject.*, coreRealm ); + // imports.put( com.google.inject.binder.*, coreRealm ); + // imports.put( com.google.inject.matcher.*, coreRealm ); + // imports.put( com.google.inject.name.*, coreRealm ); + // imports.put( com.google.inject.spi.*, coreRealm ); + // imports.put( com.google.inject.util.*, coreRealm ); } /** Modified: maven/maven-3/trunk/maven-embedder/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-embedder/pom.xml?rev=1380105r1=1380104r2=1380105view=diff
Re: JSR330 Support
looks better now. core its scheduled to run. 2012/9/3 Anders Hammar and...@hammar.net: It's up now. The last build with these changes failed though, but it's when jaring one of the modules. I can't trigger a manual build so I can't tell if it was a hiccup or what. /Anders On Mon, Sep 3, 2012 at 3:13 AM, Jason van Zyl ja...@tesla.io wrote: I just committed support for JSR330 components in extensions and plugins. It's building fine on my CI machine and the ITs work, and I'm trying on the official grid but builds.apache.org appears to be down[1]. I'll check in the morning, but if there are any problems feel free to roll back. I can't tell at the moment. [1]: http://www.downforeveryoneorjustme.com/builds.apache.org 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 -- 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
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/
I'm not seeing log4j-over-slf4j in the dependency tree there at all... so where is the bridge? On 3 September 2012 08:10, Mark Struberg strub...@yahoo.de wrote: whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java (original) +++ maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java Mon Sep 3 01:07:31 2012 @@ -198,6 +198,26 @@ public class DefaultClassRealmManager imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParser, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParserException, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlSerializer, coreRealm ); + +// javax.inject, sisu-inject (JSR-330) +imports.put( javax.inject.*, coreRealm ); +imports.put( javax.enterprise.inject.*, coreRealm ); +imports.put( org.sonatype.inject.*, coreRealm ); +imports.put( org.slf4j.*, coreRealm ); + +// com.google +// +// We may potentially want to export these, but right now I'm not sure that anything Guice specific needs +// to be made available to plugin authors. If we find people are getting fancy and want to take advantage +// of Guice specifics we can expose that later. Really some testing needs to be done to see full hiding +// of Guice has any impact on what we may categorize as a standard JSR-330 based Tesla/Maven plugin. +// +// imports.put( com.google.inject.*, coreRealm ); +// imports.put( com.google.inject.binder.*, coreRealm ); +// imports.put( com.google.inject.matcher.*, coreRealm ); +// imports.put( com.google.inject.name.*, coreRealm ); +// imports.put( com.google.inject.spi.*, coreRealm ); +// imports.put( com.google.inject.util.*, coreRealm ); } /** Modified:
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/
imports.put( org.slf4j.*, coreRealm ); To me this looks like any org.slf4j sub package would be exported. The whole goal of org.codehaus.plexus.logging.Logger was to shield the user from ANY specific logging framework. That way we could back the plexus Logger with any implementation the user wants. We already HAVE a logging bridge. Imo there is just no need to introduce another one! To kind of hardcode this now to slf4j is frankly speaking nonsense imo. But maybe I just missed the point? What is the reason for it? LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, September 3, 2012 10:42 AM Subject: 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/ I'm not seeing log4j-over-slf4j in the dependency tree there at all... so where is the bridge? On 3 September 2012 08:10, Mark Struberg strub...@yahoo.de wrote: whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java (original) +++ maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java Mon Sep 3 01:07:31 2012 @@ -198,6 +198,26 @@ public class DefaultClassRealmManager imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParser, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParserException, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlSerializer, coreRealm ); + + // javax.inject, sisu-inject (JSR-330) + imports.put( javax.inject.*, coreRealm ); + imports.put( javax.enterprise.inject.*, coreRealm ); + imports.put( org.sonatype.inject.*, coreRealm ); + imports.put( org.slf4j.*, coreRealm ); + + // com.google + // + // We may
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 3 September 2012 09:59, Mark Struberg strub...@yahoo.de wrote: imports.put( org.slf4j.*, coreRealm ); To me this looks like any org.slf4j sub package would be exported. slf4j is such a ubiquitous logging framework that it seems to me that it would make sense to allow any plugins that have dependencies that use slf4j to log through to maven. The whole goal of org.codehaus.plexus.logging.Logger was to shield the user from ANY specific logging framework. That way we could back the plexus Logger with any implementation the user wants. We already HAVE a logging bridge. Imo there is just no need to introduce another one! That is fine for plugin code, but why should *everyone* else have to rewrite the same bridge from slf4j to our logging bridge? And then that bridge routes back to slf4j? To kind of hardcode this now to slf4j is frankly speaking nonsense imo. Perhaps. I have concerns about slf4j API stability having seen some issues with slf4j 1.5 vs 1.6 which I resolved and forgot about. A simpler approach would be to produce a bridge dependency: slf4j-maven so that everyone that has dependencies that use slf4j can trivially route their dependency logging through to maven But maybe I just missed the point? What is the reason for it? Consider jetty:run... jetty sends its logging to slf4j... so to play properly the plugin *should* be picking up those logs and routing them through to Maven so that Maven's logging controls can correctly filter the logs... now tomcat:run needs to do the same, etc There is logging bridge madness all over the shop. Logging bridges should be as close to the logger as possible, especially in a short lived tool such as Maven, where the JVM may not have had a chance to optimize out the bridge. For server classes such as, e.g. MyFaces, the use of a bridge is less of an issue as the JVM will optimize it out of the code since there is only one trivial implementation and that can be in-lined and reduced away to a direct call. But a build tool that is invoking other 3rd party libs on a short lived lifecycle will have a performance hit for the logging calls. That is the argument for exposing directly. The argument against is that slf4j's API sucks... though it sucks less than any other logging api out there at the moment... there are still issues with it ;-) LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, September 3, 2012 10:42 AM Subject: 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/ I'm not seeing log4j-over-slf4j in the dependency tree there at all... so where is the bridge? On 3 September 2012 08:10, Mark Struberg strub...@yahoo.de wrote: whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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:
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/
A simpler approach would be to produce a bridge dependency: slf4j-maven so that everyone that has dependencies that use slf4j can trivially route their dependency logging through to maven +1 for taking this route. That would also allow us to adopt easily for future API changes. Been there, done that ... LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, September 3, 2012 11:55 AM Subject: 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 3 September 2012 09:59, Mark Struberg strub...@yahoo.de wrote: imports.put( org.slf4j.*, coreRealm ); To me this looks like any org.slf4j sub package would be exported. slf4j is such a ubiquitous logging framework that it seems to me that it would make sense to allow any plugins that have dependencies that use slf4j to log through to maven. The whole goal of org.codehaus.plexus.logging.Logger was to shield the user from ANY specific logging framework. That way we could back the plexus Logger with any implementation the user wants. We already HAVE a logging bridge. Imo there is just no need to introduce another one! That is fine for plugin code, but why should *everyone* else have to rewrite the same bridge from slf4j to our logging bridge? And then that bridge routes back to slf4j? To kind of hardcode this now to slf4j is frankly speaking nonsense imo. Perhaps. I have concerns about slf4j API stability having seen some issues with slf4j 1.5 vs 1.6 which I resolved and forgot about. A simpler approach would be to produce a bridge dependency: slf4j-maven so that everyone that has dependencies that use slf4j can trivially route their dependency logging through to maven But maybe I just missed the point? What is the reason for it? Consider jetty:run... jetty sends its logging to slf4j... so to play properly the plugin *should* be picking up those logs and routing them through to Maven so that Maven's logging controls can correctly filter the logs... now tomcat:run needs to do the same, etc There is logging bridge madness all over the shop. Logging bridges should be as close to the logger as possible, especially in a short lived tool such as Maven, where the JVM may not have had a chance to optimize out the bridge. For server classes such as, e.g. MyFaces, the use of a bridge is less of an issue as the JVM will optimize it out of the code since there is only one trivial implementation and that can be in-lined and reduced away to a direct call. But a build tool that is invoking other 3rd party libs on a short lived lifecycle will have a performance hit for the logging calls. That is the argument for exposing directly. The argument against is that slf4j's API sucks... though it sucks less than any other logging api out there at the moment... there are still issues with it ;-) LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, September 3, 2012 10:42 AM Subject: 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/ I'm not seeing log4j-over-slf4j in the dependency tree there at all... so where is the bridge? On 3 September 2012 08:10, Mark Struberg strub...@yahoo.de wrote: whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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
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 3, 2012, at 5:55 AM, Stephen Connolly wrote: On 3 September 2012 09:59, Mark Struberg strub...@yahoo.de wrote: imports.put( org.slf4j.*, coreRealm ); To me this looks like any org.slf4j sub package would be exported. slf4j is such a ubiquitous logging framework that it seems to me that it would make sense to allow any plugins that have dependencies that use slf4j to log through to maven. That is my thinking. It's easy enough to plugin any default implementation, and the funnels for all the logging systems work well. Ideally we pick an implementation and put in the funnels for JDK and commons-logging and we're set indefinitely, I think. The whole goal of org.codehaus.plexus.logging.Logger was to shield the user from ANY specific logging framework. That way we could back the plexus Logger with any implementation the user wants. We already HAVE a logging bridge. Imo there is just no need to introduce another one! That is fine for plugin code, but why should *everyone* else have to rewrite the same bridge from slf4j to our logging bridge? And then that bridge routes back to slf4j? To kind of hardcode this now to slf4j is frankly speaking nonsense imo. Perhaps. I have concerns about slf4j API stability having seen some issues with slf4j 1.5 vs 1.6 which I resolved and forgot about. A simpler approach would be to produce a bridge dependency: slf4j-maven so that everyone that has dependencies that use slf4j can trivially route their dependency logging through to maven But maybe I just missed the point? What is the reason for it? Consider jetty:run... jetty sends its logging to slf4j... so to play properly the plugin *should* be picking up those logs and routing them through to Maven so that Maven's logging controls can correctly filter the logs... now tomcat:run needs to do the same, etc There is logging bridge madness all over the shop. Logging bridges should be as close to the logger as possible, especially in a short lived tool such as Maven, where the JVM may not have had a chance to optimize out the bridge. For server classes such as, e.g. MyFaces, the use of a bridge is less of an issue as the JVM will optimize it out of the code since there is only one trivial implementation and that can be in-lined and reduced away to a direct call. But a build tool that is invoking other 3rd party libs on a short lived lifecycle will have a performance hit for the logging calls. That is the argument for exposing directly. The argument against is that slf4j's API sucks... though it sucks less than any other logging api out there at the moment... there are still issues with it ;-) I think it's the best and most reasonable choice which is why I added it. With the funnel support and being able to pick any default implementation I think it satisfies core requirements and is helpful for extensions. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, September 3, 2012 10:42 AM Subject: 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/ I'm not seeing log4j-over-slf4j in the dependency tree there at all... so where is the bridge? On 3 September 2012 08:10, Mark Struberg strub...@yahoo.de wrote: whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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:
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/
I disagree and believe making another API is of little value, especially given the ubiquity of SLF4J. Benefits: - Ubiquity. SLF4J may not be perfect, but I doubt we'll make anything better - 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 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. Downsides: - I'm sure users and integrators do not want to see another logging API - No injectable loggers - We would have to write all the bridges again to integrate all the other frameworks and I really don't see this as a valuable exercise. I have never seen integration issues with SLF4J in m2e or Nexus and they are fairly extensive programs. In summary I see this as low value work with no real benefit to anyone. At any rate I don't want to get in a religious debate about logging frameworks, i just want to most reasonable solution that exists without doing any work. If we all agree SLF4J is not appropriate, let me know and I'll rollback my commit and change it. On Sep 3, 2012, at 6:01 AM, Mark Struberg wrote: A simpler approach would be to produce a bridge dependency: slf4j-maven so that everyone that has dependencies that use slf4j can trivially route their dependency logging through to maven +1 for taking this route. That would also allow us to adopt easily for future API changes. Been there, done that ... LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Monday, September 3, 2012 11:55 AM Subject: 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 3 September 2012 09:59, Mark Struberg strub...@yahoo.de wrote: imports.put( org.slf4j.*, coreRealm ); To me this looks like any org.slf4j sub package would be exported. slf4j is such a ubiquitous logging framework that it seems to me that it would make sense to allow any plugins that have dependencies that use slf4j to log through to maven. The whole goal of org.codehaus.plexus.logging.Logger was to shield the user from ANY specific logging framework. That way we could back the plexus Logger with any implementation the user wants. We already HAVE a logging bridge. Imo there is just no need to introduce another one! That is fine for plugin code, but why should *everyone* else have to rewrite the same bridge from slf4j to our logging bridge? And then that bridge routes back to slf4j? To kind of hardcode this now to slf4j is frankly speaking nonsense imo. Perhaps. I have concerns about slf4j API stability having seen some issues with slf4j 1.5 vs 1.6 which I resolved and forgot about. A simpler approach would be to produce a bridge dependency: slf4j-maven so that everyone that has dependencies that use slf4j can trivially route their dependency logging through to maven But maybe I just missed the point? What is the reason for it? Consider jetty:run... jetty sends its logging to slf4j... so to play properly the plugin *should* be picking up those logs and routing them through to Maven so that Maven's logging controls can correctly filter the logs... now tomcat:run needs to do the same, etc There is logging bridge madness all over the shop. Logging bridges should be as close to the logger as possible, especially in a short lived tool such as Maven, where the JVM may not have had a chance to optimize out the bridge. For server classes such as, e.g. MyFaces, the use of a bridge is less of an issue as the JVM will optimize it out of the code since there is only one trivial implementation and that can be in-lined and reduced away to a direct call. But a build tool that is invoking other 3rd party libs on a short lived lifecycle will have a performance hit for the logging calls. That is the argument for exposing directly. The argument against is that slf4j's API sucks... though it sucks less than any other logging api out there at the moment... there are still issues with it ;-) LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List
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/
FWIW, we are using sfl4j and logback as part of m2e embedded maven runtime for over a year now without any major issues. There was a problem with older IBM JVMs [1], but it is fixed now in slf4j (and in IBM code too, as far as I understand). [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=338252 -- Regards, Igor On 12-09-03 3:10 AM, Mark Struberg wrote: whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java (original) +++ maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java Mon Sep 3 01:07:31 2012 @@ -198,6 +198,26 @@ public class DefaultClassRealmManager imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParser, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParserException, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlSerializer, coreRealm ); + +// javax.inject, sisu-inject (JSR-330) +imports.put( javax.inject.*, coreRealm ); +imports.put( javax.enterprise.inject.*, coreRealm ); +imports.put( org.sonatype.inject.*, coreRealm ); +imports.put( org.slf4j.*, coreRealm ); + +// com.google +// +// We may potentially want to export these, but right now I'm not sure that anything Guice specific needs +// to be made available to plugin authors. If we find people are getting fancy and want to take advantage +// of Guice specifics we can expose that later. Really some testing needs to be done to see full hiding +// of Guice has any impact on what we may categorize as a standard JSR-330 based Tesla/Maven plugin. +// +// imports.put( com.google.inject.*, coreRealm ); +// imports.put( com.google.inject.binder.*, coreRealm ); +// imports.put( com.google.inject.matcher.*, coreRealm ); +// imports.put( com.google.inject.name.*, coreRealm ); +// imports.put( com.google.inject.spi.*, coreRealm ); +// imports.put( com.google.inject.util.*, coreRealm ); } /** Modified:
[RESULT] [VOTE] Release Maven EAR Plugin version 2.8
Hi, The vote has passed with the following result : +1 (binding): Hervé Boutemy, Mark Struberg, Olivier Lamy and Stéphane Nicoll +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. Best, S. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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/
but you don't expose it to maven plugins, do you? I guess not, because it was not in the root realm classpath. LieGrue, strub - Original Message - From: Igor Fedorenko i...@ifedorenko.com To: dev@maven.apache.org Cc: Sent: Monday, September 3, 2012 2:25 PM Subject: 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/ FWIW, we are using sfl4j and logback as part of m2e embedded maven runtime for over a year now without any major issues. There was a problem with older IBM JVMs [1], but it is fixed now in slf4j (and in IBM code too, as far as I understand). [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=338252 -- Regards, Igor On 12-09-03 3:10 AM, Mark Struberg wrote: whats the reason for the slf4j bridge? This is kown to trash old plugins which use log4j because it clashes with it's namespace and only partly implements the log4j classes. I personally ind slf4j nice, but for older projects which use commons-logging or log4j already (and where you cant fiddle around with their sources) this broke way too many things for me. Why is this needed at all? Has nothing to do with JSR-330. LieGrue, strub - Original Message - From: jvan...@apache.org jvan...@apache.org To: comm...@maven.apache.org Cc: Sent: Monday, September 3, 2012 3:07 AM Subject: 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/ 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/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java (original) +++ maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java Mon Sep 3 01:07:31 2012 @@ -198,6 +198,26 @@ public class DefaultClassRealmManager imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParser, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParserException, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlSerializer, coreRealm ); + + // javax.inject, sisu-inject (JSR-330) + imports.put( javax.inject.*, coreRealm ); + imports.put( javax.enterprise.inject.*, coreRealm ); + imports.put( org.sonatype.inject.*, coreRealm ); + imports.put( org.slf4j.*, coreRealm ); + + // com.google + // + // We may potentially want to export these, but right now I'm not sure that anything Guice specific needs + // to be made available to plugin authors. If we
Re: Release request for maven-installer-plugin
Hi, I wanted to ask if there is any progress here? Kind regards Felix Am 2012-08-10 11:17, schrieb Olivier Lamy: Hi, Except someone beat, I can work on that after my next week holidays. 2012/8/8 Felix Mayerhuber felix.mayerhu...@gmail.com: Hi, I don't want to seem unpolite, but I write again since I got no response and thought the mail got maybe lost. Is there a release for the maven installer plugin in the near future planned? Kind regards, Felix Am 2012-08-01 09:47, schrieb Felix Mayerhuber: Hi @all, I hope I'm in the correct list for this question. When is the release of the maven installer plugin version 2.4 planned? I would need at least the fix for MINSTALL-73. Kind regards, Felix - 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: Release request for maven-installer-plugin
thanks for the ping :-). I will 2012/9/3 Felix Mayerhuber felix.mayerhu...@gmail.com: Hi, I wanted to ask if there is any progress here? Kind regards Felix Am 2012-08-10 11:17, schrieb Olivier Lamy: Hi, Except someone beat, I can work on that after my next week holidays. 2012/8/8 Felix Mayerhuber felix.mayerhu...@gmail.com: Hi, I don't want to seem unpolite, but I write again since I got no response and thought the mail got maybe lost. Is there a release for the maven installer plugin in the near future planned? Kind regards, Felix Am 2012-08-01 09:47, schrieb Felix Mayerhuber: Hi @all, I hope I'm in the correct list for this question. When is the release of the maven installer plugin version 2.4 planned? I would need at least the fix for MINSTALL-73. Kind regards, Felix - 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
[VOTE] Apache Maven Install plugin 2.4
Hi, I'd like to release Maven Install plugin 2.4 We fixed 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=15112styleName=TextprojectId=11136 Staging repository: https://repository.apache.org/content/repositories/maven-031/ Staging site: http://maven.apache.org/plugins/maven-install-plugin-2.4/ (wait sync or have a look here http://maventest.apache.org/plugins/maven-install-plugin-2.4/) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks -- 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
Re: [VOTE] release maven-shade-plugin version 2.0
I don't understand why it is failing for you: it works perfectly on my machine (same Maven version), and it should work for you since the version is defined in dependencyManagement in org.apache.maven:maven-parent:22 but no problem if you need to add this little redundant information Regards, Hervé Le dimanche 2 septembre 2012 18:51:18 Benson Margulies a écrit : Hervé ~/asf/mvn/plugins/maven-shade-plugin/ /opt/apache-maven-3.0.4/bin/mvn release:prepare -Psigned_release [INFO] Scanning for projects... [ERROR] The build could not read 1 project - [Help 1] [ERROR] [ERROR] The project org.apache.maven.plugins:maven-shade-plugin:2.1-SNAPSHOT (/Users/benson/asf/mvn/plugins/maven-shade-plugin/pom.xml) has 1 error [ERROR] 'dependencies.dependency.version' for org.codehaus.plexus:plexus-component-annotations:jar is missing. @ line 140, column 17 On Sun, Sep 2, 2012 at 6:47 PM, Benson Margulies bimargul...@gmail.com wrote: OK, please consider this VOTE cancelled and I'll make a new one presently. On Sun, Sep 2, 2012 at 5:52 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 2 septembre 2012 17:22:20 Benson Margulies a écrit : Would you prefer if I respun the release? yes, I think this would be sufficient - 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
Need a build for Eclipse Doxia Editor
Hi the current Eclipse Doxia Editor build's workspace is not available and there for its advertised update site https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.feature/target/site become not found. Can someone trigger a build?? Very much appreciated -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-shade-plugin 2.0 -- attempt 2
+1, yes! thank you Benson for your patience and comittment Hervé Le dimanche 2 septembre 2012 19:03:34 Benson Margulies a écrit : We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-028/ https://repository.apache.org/content/repositories/maven-028/org/apache/mave n/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: [VOTE] release maven-shade-plugin version 2.0
my experience with maven-site-plugin multiple branches was a nightmare this gave me sufficient motivation to work on Maven 2 3 bi-compatibility, but I don't know if such magic is feasible with maven-shade-plugin Regards, Hervé Le lundi 3 septembre 2012 09:30:34 Chris Graham a écrit : +1 for a branch. Sent from my iPhone On 03/09/2012, at 6:22 AM, Mark Struberg strub...@yahoo.de wrote: This opens up another can of worms: how to deal with plugins which cannot be made maven2 compatible anymore but we like to implement a new feature? How long do we like to support maven2 at all? Will we create a branch for those plugins? LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Sunday, September 2, 2012 10:17 PM Subject: Re: [VOTE] release maven-shade-plugin version 2.0 Now we have a different problem. According to [1], the version to require Maven 3 was supposed to be 3.0, leaving 2.0 for a merely incompatible release that still worked with Maven 2.2. Folks, what's the story? Do I need to blow this up and try again as 3.0? Will someone fix what Hervé points to? [1] http://jira.codehaus.org/browse/MSHADE#selectedTab=com.atlassian.jira.plu gin.system.project%3Aversions-panel On Sun, Sep 2, 2012 at 11:38 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Sorry, I'm -0 about this: the plugin requires Maven 3 but uses an old dependency-tree which is not really Maven 3 compatible I updated the dependency in r1379995 Notice I manually removed extra directories in staging site Regards, Hervé Le vendredi 31 août 2012 18:00:45 Benson Margulies a écrit : We solved 4 issues: ** Bug * [MSHADE-103] - maven-shade-plugin does not resolve from user-defined repositories * [MSHADE-124] - Need better plan for getting dependency-reduced-pom.xml out of basedir * [MSHADE-130] - Mark mojo as threadSafe for parallel builds ** New Feature * [MSHADE-112] - New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) There are still plenty more fish in this sea. Stating repo: https://repository.apache.org/content/repositories/maven-026/ https://repository.apache.org/content/repositories/maven-026/org/apache/m ave n/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0-source-release.zi p Staging site: http://maven.apache.org/plugins/maven-shade-plugin-2.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - 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: Need a build for Eclipse Doxia Editor
done 2012/9/3 Dan Tran dant...@gmail.com: Hi the current Eclipse Doxia Editor build's workspace is not available and there for its advertised update site https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.feature/target/site become not found. Can someone trigger a build?? Very much appreciated -Dan - 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
Re: Need a build for Eclipse Doxia Editor
Thanks, Looks like the update site did not get built, need some help doxia team https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.feature/target/site still not available Thanks -D On Mon, Sep 3, 2012 at 2:33 PM, Olivier Lamy ol...@apache.org wrote: done 2012/9/3 Dan Tran dant...@gmail.com: Hi the current Eclipse Doxia Editor build's workspace is not available and there for its advertised update site https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.feature/target/site become not found. Can someone trigger a build?? Very much appreciated -Dan - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
