Maven Core to Git
Kristian/Olivier, What exactly is the issue with switching over the core to Git? I only know vaguely what the reasoning is because I happened to wander into IRC one day. I also see the Jenkins issue[1] referred to in the Infra issue[2] about the conversion but it's not clear what's happening there or if it will be fixed anytime soon. What exactly is the problem? And why doesn't this behaviour exhibit itself in some of the other Git repos we have being built under Jenkins? I see tons of other projects using Git and Jenkins so can we workaround anything specific we're doing? [1]: https://issues.jenkins-ci.org/browse/JENKINS-15803 [2]: https://issues.apache.org/jira/browse/INFRA-5390 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
[ANN] Maven Dependency Plugin 2.6 Released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin, version 2.6 The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. http://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.6/version /plugin Release Notes - Maven Dependency Plugin - Version 2.6 ** Bug * [MDEP-122] - Analyze target does not work correctly when only using a constant defined in a different module * [MDEP-124] - Dependency incorrectly reported as Unused declared * [MDEP-176] - excludes not considered in analyze? * [MDEP-205] - type configuration ignored in sources goal * [MDEP-253] - Purge does not purge released artifacts * [MDEP-256] - invoking purge-local-repository leads to deletion of %JDK_HOME%/lib/tools.jar * [MDEP-272] - purge-local-repository does nothing if certain dependencies are included * [MDEP-298] - mvn dependency:sources lists parameters 'classifier' and 'type', but manually overrides them * [MDEP-300] - Unpacking artifacts should be based on type, with fallback on file-extension * [MDEP-328] - scriptableOutput/scriptableFlag have no effect * [MDEP-353] - Unit tests fail on Windows * [MDEP-366] - NPE when running site * [MDEP-371] - useJvmChmod true by default * [MDEP-376] - -Dexcludes filtering not working anymore * [MDEP-383] - Update purge-local-repository to work in Maven 3 * [MDEP-388] - NPE in analyze-report ** Improvement * [MDEP-173] - Support 'includes' in purge-local-repository * [MDEP-246] - purge-local-repository inclusions * [MDEP-285] - Document abstract method org.apache.maven.plugin.dependency.AbstractDependencyFilterMojo.getMarkedArtifactFilter() * [MDEP-287] - Make maven-dependency-plugin @threadSafe * [MDEP-343] - Add skip parameter for copy-dependencies * [MDEP-360] - Allow using folder as dependency:get destination parameter * [MDEP-377] - use last plexus-utils 3.0.7 which is faster on copying files. * [MDEP-384] - build-classpath should be able to use the artifact's baseVersion * [MDEP-385] - Default fuzziness level should be version instead of file * [MDEP-386] - Split purge-local-repository into manual and transitive ** New Feature * [MDEP-210] - Support includes/excludes configuration in analyze * [MDEP-380] - copy-dependencies should be able to use the artifact's baseVersion * [MDEP-381] - Unpack an artifact from commandline Enjoy, -The Apache Maven team
Re: [VOTE] Maven 3.1.0
There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Core to Git
The problem is the asf builds running too often, and sometimes far too often and hence spamming the mailing lists substantially. Some of it has been solved, but there are still a few issues remaniing: As far as I can see there are two aspects of the issue: 1. A configuration error (or any kind of git corruption/inconsistency) on any of the git nodes would lead to the jenkins build running non-stop, generating mass amounts of spam on the notifications mailing lists. This issue has been solved as far as I can see; both by fixing the git configuration issue and by patching jenkins to fix the issue. This was https://issues.jenkins-ci.org/browse/JENKINS-15803. 2. There is a second issue where any kind of intermittent disconnect between the main jenkins instance and its node will trigger a rebuild because the master does not distinguish between a node being blank/reconfigured and simply unavaliable at the moment. This is basically happening by workspaceOffline returning true in https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437 I've been meaning to get Olivier to add logging in this code to find out what is actually happening. It seems to me like every single glitch in the asf network is causing rebuilds. And it would appear to be a quite unstable network Kristian 2012/11/26 Jason van Zyl ja...@tesla.io: Kristian/Olivier, What exactly is the issue with switching over the core to Git? I only know vaguely what the reasoning is because I happened to wander into IRC one day. I also see the Jenkins issue[1] referred to in the Infra issue[2] about the conversion but it's not clear what's happening there or if it will be fixed anytime soon. What exactly is the problem? And why doesn't this behaviour exhibit itself in some of the other Git repos we have being built under Jenkins? I see tons of other projects using Git and Jenkins so can we workaround anything specific we're doing? [1]: https://issues.jenkins-ci.org/browse/JENKINS-15803 [2]: https://issues.apache.org/jira/browse/INFRA-5390 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven PMD Plugin 2.8
Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) 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] Maven 3.1.0
I noticed when building one of our core work projects the following which I don't think I've ever seen before: [WARNING] Checksum validation failed, expected ?xml but is 79cf978832042116fa043b3c7b2e147009d18d9d for http://localhost:/repository/all/smx3/smx3.core/8.2.2/smx3.core-8.2.2.pom Seems to do being it for my smx3.core artifact, but randomly between versions, it's possible theres a bad checksum there but the error message also looks strange, expected ?xml seems odd? Other than this so far my builds looks ok Tentative +1 non-binding. On 26/11/2012, at 7:24 PM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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] Maven 3.1.0
Is it me or is 3.1.0 downloading WAY WAY more .pom files from my version ranges that earlier versions? Also, my main core build just failed with: va:jar:13.0 (compile), com.google.inject:guice:jar:3.0 (compile), org.slf4j:slf4j-api:jar:1.5.8 (compile), net.sf.ehcache:ehcache:jar:1.6.2 (compile), javax.jcr:jcr:jar:1.0 (compile)]: Failed to read artifact descriptor for smx3:smx3.api:jar:6.0.15: Could not transfer artifact smx3:smx3.api:pom:6.0.15 from/to Nexus (http://localhost:/repository/all/): TransferFailedException: ClientProtocolException: The server failed to respond with a valid HTTP response - [Help 1] This is going thru an archiva instance on localhost, talking to a remote nexus - never had issues before with 3.0.4 anyone seen something like this? On 26/11/2012, at 11:31 PM, Mark Derricutt m...@talios.com wrote: I noticed when building one of our core work projects the following which I don't think I've ever seen before: [WARNING] Checksum validation failed, expected ?xml but is 79cf978832042116fa043b3c7b2e147009d18d9d for http://localhost:/repository/all/smx3/smx3.core/8.2.2/smx3.core-8.2.2.pom - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
FYI this was with maven-compiler-plugin 3.0 - which Olivier mentioned may have some issues? On 26/11/2012, at 11:41 PM, Mark Derricutt m...@talios.com wrote: Is it me or is 3.1.0 downloading WAY WAY more .pom files from my version ranges that earlier versions?
Re: [VOTE] Maven 3.1.0
2012/11/26 Mark Derricutt m...@talios.com: FYI this was with maven-compiler-plugin 3.0 - which Olivier mentioned may have some issues? Not issues but in some cases perf degradation (see https://jira.codehaus.org/browse/MCOMPILER-187 ) I will add a flag to be able to disable incremental stuff. Some variants of the pattern release early release often says too: add a flag to be able to disable new features :-). regarding your issue, it's hard to say what has failed. Perso I always test core too without any mrm as they can fail (and it's not the first target to test that too :-) ) On 26/11/2012, at 11:41 PM, Mark Derricutt m...@talios.com wrote: Is it me or is 3.1.0 downloading WAY WAY more .pom files from my version ranges that earlier versions? -- 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] Maven 3.1.0
What are you referring to specifically? On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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
Re: [VOTE] Maven 3.1.0
What was the issue specifically? Something you think will affect people generally? On Nov 26, 2012, at 2:43 AM, Mark Derricutt m...@talios.com wrote: FYI this was with maven-compiler-plugin 3.0 - which Olivier mentioned may have some issues? On 26/11/2012, at 11:41 PM, Mark Derricutt m...@talios.com wrote: Is it me or is 3.1.0 downloading WAY WAY more .pom files from my version ranges that earlier versions? Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: [VOTE] Release Maven PMD Plugin 2.8
I'm getting: [WARNING] Failure executing PMD: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar java.lang.RuntimeException: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar and a big long stack trace if I update to this. (this is with CXF)Any ideas? Dan On Nov 26, 2012, at 5:00 AM, Olivier Lamy ol...@apache.org wrote: Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven PMD Plugin 2.8
OK. Just read the release notes for PMD 5.0: http://sourceforge.net/projects/pmd/files/pmd/5.0.0/ PMD 5 is definitely NOT compatible with much of the configuration and custom rulesets and such that are out there. Thus, this really is a gigantic update. I would recommend canceling this and re-spin with a 3.0 version number as this is definitely not anywhere close to compatible to the 2.7 version of the plugin. Dan On Nov 26, 2012, at 9:50 AM, Daniel Kulp dk...@apache.org wrote: I'm getting: [WARNING] Failure executing PMD: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar java.lang.RuntimeException: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar and a big long stack trace if I update to this. (this is with CXF)Any ideas? Dan On Nov 26, 2012, at 5:00 AM, Olivier Lamy ol...@apache.org wrote: Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Core to Git
On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The problem is the asf builds running too often, and sometimes far too often and hence spamming the mailing lists substantially. Some of it has been solved, but there are still a few issues remaniing: As far as I can see there are two aspects of the issue: 1. A configuration error (or any kind of git corruption/inconsistency) on any of the git nodes would lead to the jenkins build running non-stop, generating mass amounts of spam on the notifications mailing lists. This issue has been solved as far as I can see; both by fixing the git configuration issue and by patching jenkins to fix the issue. This was https://issues.jenkins-ci.org/browse/JENKINS-15803. 2. There is a second issue where any kind of intermittent disconnect between the main jenkins instance and its node will trigger a rebuild because the master does not distinguish between a node being blank/reconfigured and simply unavaliable at the moment. This is basically happening by workspaceOffline returning true in https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437 I've been meaning to get Olivier to add logging in this code to find out what is actually happening. It seems to me like every single glitch in the asf network is causing rebuilds. And it would appear to be a quite unstable network So in practical terms it all needs to be released, and the servers all updated? Can we just turn off the remote nodes for the time being and just run 1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer to do that in the short term because getting this all this working doesn't seem like it's going to happen very quickly. Kristian 2012/11/26 Jason van Zyl ja...@tesla.io: Kristian/Olivier, What exactly is the issue with switching over the core to Git? I only know vaguely what the reasoning is because I happened to wander into IRC one day. I also see the Jenkins issue[1] referred to in the Infra issue[2] about the conversion but it's not clear what's happening there or if it will be fixed anytime soon. What exactly is the problem? And why doesn't this behaviour exhibit itself in some of the other Git repos we have being built under Jenkins? I see tons of other projects using Git and Jenkins so can we workaround anything specific we're doing? [1]: https://issues.jenkins-ci.org/browse/JENKINS-15803 [2]: https://issues.apache.org/jira/browse/INFRA-5390 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - 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 - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: [VOTE] Maven 3.1.0
2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- 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 PMD Plugin 2.8
2012/11/26 Daniel Kulp dk...@apache.org: OK. Just read the release notes for PMD 5.0: http://sourceforge.net/projects/pmd/files/pmd/5.0.0/ PMD 5 is definitely NOT compatible with much of the configuration and custom rulesets and such that are out there. Thus, this really is a gigantic update. I would recommend canceling this and re-spin with a 3.0 version number as this is definitely not anywhere close to compatible to the 2.7 version of the plugin. Sounds a good reason. I will re start the release with a 3.0 version number Dan On Nov 26, 2012, at 9:50 AM, Daniel Kulp dk...@apache.org wrote: I'm getting: [WARNING] Failure executing PMD: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar java.lang.RuntimeException: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar and a big long stack trace if I update to this. (this is with CXF)Any ideas? Dan On Nov 26, 2012, at 5:00 AM, Olivier Lamy ol...@apache.org wrote: Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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] Maven 3.1.0
On Nov 26, 2012, at 7:28 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? If this is not an edict for releases I really do not see the point of manually making a bunch of svn repository and manually copying a bunch of stuff around when the staging repository in Nexus works perfectly fine. It's error prone, as all manual copying things are, we don't do this for other releases so I assume this is not an official requirements. If it is acceptable by official guidelines I would like to leave them in the Nexus staging repository and not copying a bunch of stuff around. For the final release I will do the SVN dist stuff but honestly doesn't seem to add much value for the interim releases and I would rather be consistent with the other releases that don't do this. The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- 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 - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: [VOTE] Maven 3.1.0
On Nov 26, 2012, at 7:28 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. More to the point what is it that we're really trying to do here? To me it's to make it available for people to try easily in a way that is the least error prone way possible. To pull down a bunch of stuff to my machine, make some SVN directories and then push it back up simply doesn't seem necessary. Benson already tried the first version from Nexus so is this honestly an unreasonable practice. I think the RM's duty is just to make the bits available for verification in a consistent way. We generally use the directory that our build outputs which in our case is: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ I know what the document says but does that really make sense? Does anyone think it unreasonable to simply use the Nexus staging repository? It's automated, less error prone, easy to remove and to me just makes more sense given our release tool chain. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. This needs to be stored forever so if SVN is being used for the canonical releases then so be it. I think it's an odd use of SVN but when you have the SVN hammer ... On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- 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 - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it
Re: [VOTE] Maven 3.1.0
2012/11/26 Jason van Zyl ja...@tesla.io: On Nov 26, 2012, at 7:28 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? If this is not an edict for releases I really do not see the point of manually making a bunch of svn repository and manually copying a bunch of stuff around when the staging repository in Nexus works perfectly fine. It's error prone, as all manual copying things are, we don't do this for other releases so I assume this is not an official requirements. If it is acceptable by official guidelines I would like to leave them in the Nexus staging repository and not copying a bunch of stuff around. For the final release I will do the SVN dist stuff but honestly doesn't seem to add much value for the interim releases and I would rather be consistent with the other releases that don't do this. Previously we proposed for for download the artifacts going to Apache distribution part in people.apache.org. To say : this will be distributed. Here what will you put in the Apache download part ? That's to ease testing and validation. If you don't want to do as it's documented it's your choice! That's just an easy way to do as at the end you still have to do that ! This maybe need The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- 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 - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things,
Re: [VOTE] Maven 3.1.0
I just don't know if it's officially required. If I have to then I have no choice. If it's not officially required I'll use the Nexus staging repository. On Nov 26, 2012, at 7:49 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: On Nov 26, 2012, at 7:28 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? If this is not an edict for releases I really do not see the point of manually making a bunch of svn repository and manually copying a bunch of stuff around when the staging repository in Nexus works perfectly fine. It's error prone, as all manual copying things are, we don't do this for other releases so I assume this is not an official requirements. If it is acceptable by official guidelines I would like to leave them in the Nexus staging repository and not copying a bunch of stuff around. For the final release I will do the SVN dist stuff but honestly doesn't seem to add much value for the interim releases and I would rather be consistent with the other releases that don't do this. Previously we proposed for for download the artifacts going to Apache distribution part in people.apache.org. To say : this will be distributed. Here what will you put in the Apache download part ? That's to ease testing and validation. If you don't want to do as it's documented it's your choice! That's just an easy way to do as at the end you still have to do that ! This maybe need The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- 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
Re: [VOTE] Maven 3.1.0
2012/11/26 Jason van Zyl ja...@tesla.io: I just don't know if it's officially required. If I have to then I have no choice. If it's not officially required I'll use the Nexus staging repository. Some other projects @asf do as it so I copied this procedure. At the end you will need to do it for the distribution part. Again you're the rm so it's your choice. Procedures can be not perfect, in such case they can be updated/modified. That just need to be documented. So if you want to remove this part from the release process just update the documentation. And that will avoid this waste of time for all. On Nov 26, 2012, at 7:49 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: On Nov 26, 2012, at 7:28 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? If this is not an edict for releases I really do not see the point of manually making a bunch of svn repository and manually copying a bunch of stuff around when the staging repository in Nexus works perfectly fine. It's error prone, as all manual copying things are, we don't do this for other releases so I assume this is not an official requirements. If it is acceptable by official guidelines I would like to leave them in the Nexus staging repository and not copying a bunch of stuff around. For the final release I will do the SVN dist stuff but honestly doesn't seem to add much value for the interim releases and I would rather be consistent with the other releases that don't do this. Previously we proposed for for download the artifacts going to Apache distribution part in people.apache.org. To say : this will be distributed. Here what will you put in the Apache download part ? That's to ease testing and validation. If you don't want to do as it's documented it's your choice! That's just an easy way to do as at the end you still have to do that ! This maybe need The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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.
Re: [VOTE] Maven 3.1.0
FWIW: I agree with Jason on this. It's already staged in Nexus, there really isn't a point (to me) to stage it yet someplace else. If the vote fails, that would then mean multiple places to have to go to to drop things, cleanup, etc… More steps means more things are likely to be forgotten. I'm failing to see the point of sticking it in SVN in addition to the Nexus staging area. Dan On Nov 26, 2012, at 10:47 AM, Jason van Zyl ja...@tesla.io wrote: On Nov 26, 2012, at 7:28 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. More to the point what is it that we're really trying to do here? To me it's to make it available for people to try easily in a way that is the least error prone way possible. To pull down a bunch of stuff to my machine, make some SVN directories and then push it back up simply doesn't seem necessary. Benson already tried the first version from Nexus so is this honestly an unreasonable practice. I think the RM's duty is just to make the bits available for verification in a consistent way. We generally use the directory that our build outputs which in our case is: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ I know what the document says but does that really make sense? Does anyone think it unreasonable to simply use the Nexus staging repository? It's automated, less error prone, easy to remove and to me just makes more sense given our release tool chain. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. This needs to be stored forever so if SVN is being used for the canonical releases then so be it. I think it's an odd use of SVN but when you have the SVN hammer ... On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [VOTE] Maven 3.1.0
On Nov 26, 2012, at 8:03 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: I just don't know if it's officially required. If I have to then I have no choice. If it's not officially required I'll use the Nexus staging repository. Some other projects @asf do as it so I copied this procedure. At the end you will need to do it for the distribution part. Again you're the rm so it's your choice. Procedures can be not perfect, in such case they can be updated/modified. That just need to be documented. So if you want to remove this part from the release process just update the documentation. And that will avoid this waste of time for all. Ok, will do. I'll update the doco. I might try and write a small plugin for Nexus for releases. When the staging repo is released it can push the right artifacts to the SVN depot. On Nov 26, 2012, at 7:49 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: On Nov 26, 2012, at 7:28 AM, Olivier Lamy ol...@apache.org wrote: 2012/11/26 Jason van Zyl ja...@tesla.io: What are you referring to specifically? If this is not an edict for releases I really do not see the point of manually making a bunch of svn repository and manually copying a bunch of stuff around when the staging repository in Nexus works perfectly fine. It's error prone, as all manual copying things are, we don't do this for other releases so I assume this is not an official requirements. If it is acceptable by official guidelines I would like to leave them in the Nexus staging repository and not copying a bunch of stuff around. For the final release I will do the SVN dist stuff but honestly doesn't seem to add much value for the interim releases and I would rather be consistent with the other releases that don't do this. Previously we proposed for for download the artifacts going to Apache distribution part in people.apache.org. To say : this will be distributed. Here what will you put in the Apache download part ? That's to ease testing and validation. If you don't want to do as it's documented it's your choice! That's just an easy way to do as at the end you still have to do that ! This maybe need The goal is to commit candidate release to svn tree https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then once the vote passed svn move to https://dist.apache.org/repos/dist/release/maven/maven-3/$VERSION. On Nov 26, 2012, at 12:24 AM, Olivier Lamy ol...@apache.org wrote: There is a procedure described here http://maven.apache.org/developers/release/maven-core-release.html with a place for zip,tarball etc.. Why not following that ? -- Olivier Le 26 nov. 2012 07:24, Jason van Zyl ja...@tesla.io a écrit : Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:
Re: Maven Core to Git
On 2012-11-26 15:59, Jason van Zyl wrote: On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The problem is the asf builds running too often, and sometimes far too often and hence spamming the mailing lists substantially. Some of it has been solved, but there are still a few issues remaniing: As far as I can see there are two aspects of the issue: 1. A configuration error (or any kind of git corruption/inconsistency) on any of the git nodes would lead to the jenkins build running non-stop, generating mass amounts of spam on the notifications mailing lists. This issue has been solved as far as I can see; both by fixing the git configuration issue and by patching jenkins to fix the issue. This was https://issues.jenkins-ci.org/browse/JENKINS-15803. 2. There is a second issue where any kind of intermittent disconnect between the main jenkins instance and its node will trigger a rebuild because the master does not distinguish between a node being blank/reconfigured and simply unavaliable at the moment. This is basically happening by workspaceOffline returning true in https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437 I've been meaning to get Olivier to add logging in this code to find out what is actually happening. It seems to me like every single glitch in the asf network is causing rebuilds. And it would appear to be a quite unstable network So in practical terms it all needs to be released, and the servers all updated? There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Can we just turn off the remote nodes for the time being and just run 1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer to do that in the short term because getting this all this working doesn't seem like it's going to happen very quickly. Which ubuntu node would that be? There are 5 of them and I think they are all slaves. Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? Kristian 2012/11/26 Jason van Zyl ja...@tesla.io: Kristian/Olivier, What exactly is the issue with switching over the core to Git? I only know vaguely what the reasoning is because I happened to wander into IRC one day. I also see the Jenkins issue[1] referred to in the Infra issue[2] about the conversion but it's not clear what's happening there or if it will be fixed anytime soon. What exactly is the problem? And why doesn't this behaviour exhibit itself in some of the other Git repos we have being built under Jenkins? I see tons of other projects using Git and Jenkins so can we workaround anything specific we're doing? [1]: https://issues.jenkins-ci.org/browse/JENKINS-15803 [2]: https://issues.apache.org/jira/browse/INFRA-5390 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - 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 - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Core to Git
On Nov 26, 2012, at 10:41 AM, Dennis Lundberg denn...@apache.org wrote: On 2012-11-26 15:59, Jason van Zyl wrote: On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The problem is the asf builds running too often, and sometimes far too often and hence spamming the mailing lists substantially. Some of it has been solved, but there are still a few issues remaniing: As far as I can see there are two aspects of the issue: 1. A configuration error (or any kind of git corruption/inconsistency) on any of the git nodes would lead to the jenkins build running non-stop, generating mass amounts of spam on the notifications mailing lists. This issue has been solved as far as I can see; both by fixing the git configuration issue and by patching jenkins to fix the issue. This was https://issues.jenkins-ci.org/browse/JENKINS-15803. 2. There is a second issue where any kind of intermittent disconnect between the main jenkins instance and its node will trigger a rebuild because the master does not distinguish between a node being blank/reconfigured and simply unavaliable at the moment. This is basically happening by workspaceOffline returning true in https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437 I've been meaning to get Olivier to add logging in this code to find out what is actually happening. It seems to me like every single glitch in the asf network is causing rebuilds. And it would appear to be a quite unstable network So in practical terms it all needs to be released, and the servers all updated? There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Can we just turn off the remote nodes for the time being and just run 1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer to do that in the short term because getting this all this working doesn't seem like it's going to happen very quickly. Which ubuntu node would that be? There are 5 of them and I think they are all slaves. Just run on one machine for the matrix of JDKs we care about if this prevents the build explosions. Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. We have already haven't we? Apart from that I've done hundreds of releases out of Git and it works fine. But for core I will take responsibility if the buck needs to stop somewhere. I just want to get it moved over and work around any issues until the problems are solved. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? The release plugin works fine with Git. Kristian 2012/11/26 Jason van Zyl ja...@tesla.io: Kristian/Olivier, What exactly is the issue with switching over the core to Git? I only know vaguely what the reasoning is because I happened to wander into IRC one day. I also see the Jenkins issue[1] referred to in the Infra issue[2] about the conversion but it's not clear what's happening there or if it will be fixed anytime soon. What exactly is the problem? And why doesn't this behaviour exhibit itself in some of the other Git repos we have being built under Jenkins? I see tons of other projects using Git and Jenkins so can we workaround anything specific we're doing? [1]: https://issues.jenkins-ci.org/browse/JENKINS-15803 [2]: https://issues.apache.org/jira/browse/INFRA-5390 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - 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 - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob
Re: Maven Core to Git
On 2012-11-26 19:49, Jason van Zyl wrote: On Nov 26, 2012, at 10:41 AM, Dennis Lundberg denn...@apache.org wrote: On 2012-11-26 15:59, Jason van Zyl wrote: On Nov 26, 2012, at 12:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The problem is the asf builds running too often, and sometimes far too often and hence spamming the mailing lists substantially. Some of it has been solved, but there are still a few issues remaniing: As far as I can see there are two aspects of the issue: 1. A configuration error (or any kind of git corruption/inconsistency) on any of the git nodes would lead to the jenkins build running non-stop, generating mass amounts of spam on the notifications mailing lists. This issue has been solved as far as I can see; both by fixing the git configuration issue and by patching jenkins to fix the issue. This was https://issues.jenkins-ci.org/browse/JENKINS-15803. 2. There is a second issue where any kind of intermittent disconnect between the main jenkins instance and its node will trigger a rebuild because the master does not distinguish between a node being blank/reconfigured and simply unavaliable at the moment. This is basically happening by workspaceOffline returning true in https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L1437 I've been meaning to get Olivier to add logging in this code to find out what is actually happening. It seems to me like every single glitch in the asf network is causing rebuilds. And it would appear to be a quite unstable network So in practical terms it all needs to be released, and the servers all updated? There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Can we just turn off the remote nodes for the time being and just run 1.5/1.6/1.7 on the Ubuntu node? Is that a valid work around? I would prefer to do that in the short term because getting this all this working doesn't seem like it's going to happen very quickly. Which ubuntu node would that be? There are 5 of them and I think they are all slaves. Just run on one machine for the matrix of JDKs we care about if this prevents the build explosions. Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. We have already haven't we? Apart from that I've done hundreds of releases out of Git and it works fine. But for core I will take responsibility if the buck needs to stop somewhere. I just want to get it moved over and work around any issues until the problems are solved. Like I said, I don't know the current status on this. It might very well be that we are there now. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? The release plugin works fine with Git. I'm sure it does. But for git beginners like myself who has not done a single release using git, we need a well documented release process for it. Kristian 2012/11/26 Jason van Zyl ja...@tesla.io: Kristian/Olivier, What exactly is the issue with switching over the core to Git? I only know vaguely what the reasoning is because I happened to wander into IRC one day. I also see the Jenkins issue[1] referred to in the Infra issue[2] about the conversion but it's not clear what's happening there or if it will be fixed anytime soon. What exactly is the problem? And why doesn't this behaviour exhibit itself in some of the other Git repos we have being built under Jenkins? I see tons of other projects using Git and Jenkins so can we workaround anything specific we're doing? [1]: https://issues.jenkins-ci.org/browse/JENKINS-15803 [2]: https://issues.apache.org/jira/browse/INFRA-5390 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - 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
Re: [VOTE] Release Maven PMD Plugin 2.8
Hi, you might want to wait with the new PMD Plugin until end of this week. I plan to release PMD 5.0.1 this week, which brings a couple of bugfixes: https://sourceforge.net/p/pmd/bugs/milestone/PMD-5.0.1/ Additionally, I verified that the following two issues would be fixed with 5.0.1, too: http://jira.codehaus.org/browse/MPMD-126 http://jira.codehaus.org/browse/MPMD-139 It should be only a matter of updating the dependency. Thanks, Andreas On 26.11.2012 16:32, schrieb Olivier Lamy: 2012/11/26 Daniel Kulpdk...@apache.org: OK. Just read the release notes for PMD 5.0: http://sourceforge.net/projects/pmd/files/pmd/5.0.0/ PMD 5 is definitely NOT compatible with much of the configuration and custom rulesets and such that are out there. Thus, this really is a gigantic update. I would recommend canceling this and re-spin with a 3.0 version number as this is definitely not anywhere close to compatible to the 2.7 version of the plugin. Sounds a good reason. I will re start the release with a 3.0 version number Dan On Nov 26, 2012, at 9:50 AM, Daniel Kulpdk...@apache.org wrote: I'm getting: [WARNING] Failure executing PMD: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar java.lang.RuntimeException: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar and a big long stack trace if I update to this. (this is with CXF)Any ideas? Dan On Nov 26, 2012, at 5:00 AM, Olivier Lamyol...@apache.org wrote: Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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 -- Andreas Dangel https://github.com/adangel skype: andreas_dangel - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Core to Git
There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Additionally, there is https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in remoting 4 days ago. According to the issue text it renders the slaves unusable. To which extent that makes the remote poller crash out is also unknown. But it's known that we have a *lot* of 6604 on the nodes, especially right after a restart. I am unsure what effect a single bad apple among the remote nodes has and to what extent we would detect it. Reading the jenkins code makes me quite sure that any build that is locked to 1 specific node will not encounter any of the network-down issues. I don't really understand how to get assignedNode (https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354) to be non-null but that should stop the random reallocations. I assume we could lock a few of the jobs down to given nodes and keep some open while we continue to track the problem ? Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? I believe all wagon, surefire and scm have all been released from git, so I think we're in the clear on /that/ particular aspect. Personally I think we should go ahead and convert core too. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Core to Git
Kristian, can you ping me on irc tomorrow and maybe I can put some time into sorting the issues out (from the Jenkins side) On Monday, 26 November 2012, Kristian Rosenvold wrote: There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Additionally, there is https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in remoting 4 days ago. According to the issue text it renders the slaves unusable. To which extent that makes the remote poller crash out is also unknown. But it's known that we have a *lot* of 6604 on the nodes, especially right after a restart. I am unsure what effect a single bad apple among the remote nodes has and to what extent we would detect it. Reading the jenkins code makes me quite sure that any build that is locked to 1 specific node will not encounter any of the network-down issues. I don't really understand how to get assignedNode ( https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354 ) to be non-null but that should stop the random reallocations. I assume we could lock a few of the jobs down to given nodes and keep some open while we continue to track the problem ? Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? I believe all wagon, surefire and scm have all been released from git, so I think we're in the clear on /that/ particular aspect. Personally I think we should go ahead and convert core too. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
Re: Maven Core to Git
On the jenkins question, Why don't all the other Apache projects for which I'm on the dev list suffer from this? On the RM question, I don't think it's worth waiting. The core is the thing we release least often. We've run a release or two on the components we've already migrated, and whomever runs the first core release from git can be sure to add notes to the doc. On Mon, Nov 26, 2012 at 2:44 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Kristian, can you ping me on irc tomorrow and maybe I can put some time into sorting the issues out (from the Jenkins side) On Monday, 26 November 2012, Kristian Rosenvold wrote: There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Additionally, there is https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in remoting 4 days ago. According to the issue text it renders the slaves unusable. To which extent that makes the remote poller crash out is also unknown. But it's known that we have a *lot* of 6604 on the nodes, especially right after a restart. I am unsure what effect a single bad apple among the remote nodes has and to what extent we would detect it. Reading the jenkins code makes me quite sure that any build that is locked to 1 specific node will not encounter any of the network-down issues. I don't really understand how to get assignedNode ( https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354 ) to be non-null but that should stop the random reallocations. I assume we could lock a few of the jobs down to given nodes and keep some open while we continue to track the problem ? Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? I believe all wagon, surefire and scm have all been released from git, so I think we're in the clear on /that/ particular aspect. Personally I think we should go ahead and convert core too. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Core to Git
Agree. Shit happens, we'll deal with it. For now let's just lock it down to one machine. We can also just setup individual builds on the separate machines. No big deal. jvz On 2012-11-26, at 11:18 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Additionally, there is https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in remoting 4 days ago. According to the issue text it renders the slaves unusable. To which extent that makes the remote poller crash out is also unknown. But it's known that we have a *lot* of 6604 on the nodes, especially right after a restart. I am unsure what effect a single bad apple among the remote nodes has and to what extent we would detect it. Reading the jenkins code makes me quite sure that any build that is locked to 1 specific node will not encounter any of the network-down issues. I don't really understand how to get assignedNode (https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354) to be non-null but that should stop the random reallocations. I assume we could lock a few of the jobs down to given nodes and keep some open while we continue to track the problem ? Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? I believe all wagon, surefire and scm have all been released from git, so I think we're in the clear on /that/ particular aspect. Personally I think we should go ahead and convert core too. Kristian - 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: [RESULT] [VOTE] Release Maven Invoker Plugin version 1.8
Hi, The vote has passed with the following result : +1 (binding): Robert Scholte, Olivier Lamy, Hervé BOUTEMY, Maria Odea Ching-Mallete +1 (non binding): Tamás Cservenák, Tony Chemit, Mirko Friedenhagen, Anders Hammar I will promote the artifacts to the central repo. Robert Op Fri, 23 Nov 2012 19:04:07 +0100 schreef Robert Scholte rfscho...@apache.org: Hi, We solved 14 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11441styleName=Htmlversion=18730 There are no more open bugs, but still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11441status=1 Staging repo: https://repository.apache.org/content/repositories/maven-068/ https://repository.apache.org/content/repositories/maven-068/org/apache/maven/plugins/maven-invoker-plugin/1.8/maven-invoker-plugin-1.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-invoker-plugin-1.8/maven-invoker-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 thanks, Robert - 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: Maven Core to Git
On 2012-11-26 20:18, Kristian Rosenvold wrote: There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Additionally, there is https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in remoting 4 days ago. According to the issue text it renders the slaves unusable. To which extent that makes the remote poller crash out is also unknown. But it's known that we have a *lot* of 6604 on the nodes, especially right after a restart. I am unsure what effect a single bad apple among the remote nodes has and to what extent we would detect it. Reading the jenkins code makes me quite sure that any build that is locked to 1 specific node will not encounter any of the network-down issues. I don't really understand how to get assignedNode (https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354) to be non-null but that should stop the random reallocations. I assume we could lock a few of the jobs down to given nodes and keep some open while we continue to track the problem ? Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? I believe all wagon, surefire and scm have all been released from git, so I think we're in the clear on /that/ particular aspect. Personally I think we should go ahead and convert core too. Thanks Kristian, that's all I wanted to hear. Please go ahead and convert. Just remember to document any differences between svn and git along the way. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven PMD Plugin 2.8
2012/11/26 Andreas Dangel adan...@users.sourceforge.net: Hi, you might want to wait with the new PMD Plugin until end of this week. I plan to release PMD 5.0.1 this week, which brings a couple of bugfixes: https://sourceforge.net/p/pmd/bugs/milestone/PMD-5.0.1/ Additionally, I verified that the following two issues would be fixed with 5.0.1, too: http://jira.codehaus.org/browse/MPMD-126 http://jira.codehaus.org/browse/MPMD-139 It should be only a matter of updating the dependency. Great! Sure we can wait some days more :-) Thanks -- Olivier Thanks, Andreas On 26.11.2012 16:32, schrieb Olivier Lamy: 2012/11/26 Daniel Kulpdk...@apache.org: OK. Just read the release notes for PMD 5.0: http://sourceforge.net/projects/pmd/files/pmd/5.0.0/ PMD 5 is definitely NOT compatible with much of the configuration and custom rulesets and such that are out there. Thus, this really is a gigantic update. I would recommend canceling this and re-spin with a 3.0 version number as this is definitely not anywhere close to compatible to the 2.7 version of the plugin. Sounds a good reason. I will re start the release with a 3.0 version number Dan On Nov 26, 2012, at 9:50 AM, Daniel Kulpdk...@apache.org wrote: I'm getting: [WARNING] Failure executing PMD: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar java.lang.RuntimeException: Couldn't find the class Can't find resource rulesets/basic.xml. Make sure the resource is a valid file or URL or is on the CLASSPATH. Here's the current classpath: /Users/dkulp/bin/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar and a big long stack trace if I update to this. (this is with CXF) Any ideas? Dan On Nov 26, 2012, at 5:00 AM, Olivier Lamyol...@apache.org wrote: Hi, We solved N issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18287 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-maven-074/ https://repository.apache.org/content/repositories/maven-074/org/apache/maven/plugins/maven-pmd-plugin/2.8/maven-pmd-plugin-2.8-source-release.zip Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.8/ (wait sync) 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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 -- Andreas Dangel https://github.com/adangel skype: andreas_dangel - 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: Maven Core to Git
I'm going to be working on the core for a few weeks. I am not convinced putting the ITs with the core is workable. I've tried it with a few scenarios and it's super confusing to me at least. If you're going to convert them, can you please keep them as individual repositories for now and I'd like to work with you through some use cases because I ran into some problems but you may have ways to work around them. I would prefer to merge them together later then assume it will work and have to undo it. On Nov 26, 2012, at 1:41 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-11-26 20:18, Kristian Rosenvold wrote: There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Additionally, there is https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in remoting 4 days ago. According to the issue text it renders the slaves unusable. To which extent that makes the remote poller crash out is also unknown. But it's known that we have a *lot* of 6604 on the nodes, especially right after a restart. I am unsure what effect a single bad apple among the remote nodes has and to what extent we would detect it. Reading the jenkins code makes me quite sure that any build that is locked to 1 specific node will not encounter any of the network-down issues. I don't really understand how to get assignedNode (https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354) to be non-null but that should stop the random reallocations. I assume we could lock a few of the jobs down to given nodes and keep some open while we continue to track the problem ? Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? I believe all wagon, surefire and scm have all been released from git, so I think we're in the clear on /that/ particular aspect. Personally I think we should go ahead and convert core too. Thanks Kristian, that's all I wanted to hear. Please go ahead and convert. Just remember to document any differences between svn and git along the way. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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
Re: Maven Core to Git
On Mon, Nov 26, 2012 at 11:20 PM, Jason van Zyl ja...@tesla.io wrote: I'm going to be working on the core for a few weeks. I am not convinced putting the ITs with the core is workable. I've tried it with a few scenarios and it's super confusing to me at least. +1 If you're going to convert them, can you please keep them as individual repositories for now and I'd like to work with you through some use cases because I ran into some problems but you may have ways to work around them. I would prefer to merge them together later then assume it will work and have to undo it. On Nov 26, 2012, at 1:41 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-11-26 20:18, Kristian Rosenvold wrote: There is also https://issues.jenkins-ci.org/browse/JENKINS-15367 which went into Jenkins 1.492 that was released yesterday, that may or may not be a factor in this depending who you talk to. Additionally, there is https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in remoting 4 days ago. According to the issue text it renders the slaves unusable. To which extent that makes the remote poller crash out is also unknown. But it's known that we have a *lot* of 6604 on the nodes, especially right after a restart. I am unsure what effect a single bad apple among the remote nodes has and to what extent we would detect it. Reading the jenkins code makes me quite sure that any build that is locked to 1 specific node will not encounter any of the network-down issues. I don't really understand how to get assignedNode ( https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354 ) to be non-null but that should stop the random reallocations. I assume we could lock a few of the jobs down to given nodes and keep some open while we continue to track the problem ? Apart from these issues I proposed that we release a couple of our own products using git, before we move the core over to git. Just so that we have a good grasp of how a Maven release using git is done and get it properly documented. I'm not up to date on the progress here though. Would those of you that have done such releases please let us know? I believe all wagon, surefire and scm have all been released from git, so I think we're in the clear on /that/ particular aspect. Personally I think we should go ahead and convert core too. Thanks Kristian, that's all I wanted to hear. Please go ahead and convert. Just remember to document any differences between svn and git along the way. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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 -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier
[VOTE] Maven Archetypes Parent 5 and Maven Archetype Plugin 1.2
Hi, I'd like to release the archetype for maven plugin. The goal is to have an archetype which generate project using new mojo annotations (and a sample to run maven-invoker-plugin) We fixed 2 issues: http://jira.codehaus.org/browse/MARCHETYPES/fixforversion/18708 Staging repository: https://repository.apache.org/content/repositories/maven-080/ To test it: mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-plugin -DarchetypeVersion=1.2 -DarchetypeRepository=https://repository.apache.org/content/repositories/maven-080/ 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: Maven Core to Git
On 27/11/2012, at 10:34 AM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Nov 26, 2012 at 11:20 PM, Jason van Zyl ja...@tesla.io wrote: I'm going to be working on the core for a few weeks. I am not convinced putting the ITs with the core is workable. I've tried it with a few scenarios and it's super confusing to me at least. +1 Agree - makes sense to keep them separate as they are often run against different versions of Maven. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
The problems I saw only seemed to be affected my projects where I'd updated to use 3.0 of the compiler plugin, using the default version used by maven 3.1.0 I've not seen the problem. The problem I was seeing was that Maven was downloading pretty much EVERY .pom mentioned in the upstream metadata for my version ranged artifacts and not just those from the specified range, this seemed ( from memory ) to them be pulling down all of the transitive deps for ALL versions regardless of range resolution. I'll see if I get similar behaviour here at the office on the same project. On 27/11/2012, at 3:49 AM, Jason van Zyl ja...@tesla.io wrote: What was the issue specifically? Something you think will affect people generally? On Nov 26, 2012, at 2:43 AM, Mark Derricutt m...@talios.com wrote: FYI this was with maven-compiler-plugin 3.0 - which Olivier mentioned may have some issues? On 26/11/2012, at 11:41 PM, Mark Derricutt m...@talios.com wrote: Is it me or is 3.1.0 downloading WAY WAY more .pom files from my version ranges that earlier versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
As we had some issues with an earlier staged Maven version (was it 3.0.4?) and releasing (something with nginx in front of nexus), it would be great if we could verify that we don't release something with an similar issue. So, anyone doing a release the coming days please use the staged 3.1.0! /Anders On Tue, Nov 27, 2012 at 1:17 AM, Mark Derricutt m...@talios.com wrote: The problems I saw only seemed to be affected my projects where I'd updated to use 3.0 of the compiler plugin, using the default version used by maven 3.1.0 I've not seen the problem. The problem I was seeing was that Maven was downloading pretty much EVERY .pom mentioned in the upstream metadata for my version ranged artifacts and not just those from the specified range, this seemed ( from memory ) to them be pulling down all of the transitive deps for ALL versions regardless of range resolution. I'll see if I get similar behaviour here at the office on the same project. On 27/11/2012, at 3:49 AM, Jason van Zyl ja...@tesla.io wrote: What was the issue specifically? Something you think will affect people generally? On Nov 26, 2012, at 2:43 AM, Mark Derricutt m...@talios.com wrote: FYI this was with maven-compiler-plugin 3.0 - which Olivier mentioned may have some issues? On 26/11/2012, at 11:41 PM, Mark Derricutt m...@talios.com wrote: Is it me or is 3.1.0 downloading WAY WAY more .pom files from my version ranges that earlier versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
