Re: MNG-3004/MNG-2802 - Achieving massive parallelity ?
On Tue, Dec 1, 2009 at 9:49 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I am pleased to announce that the weave mode now does a mvn clean install of a fairly regular project with any number of threads, and at great speed improvement - 2-4x is not uncommon. There are still issues to be sorted out, and I'd be really grateful for any reports of problems. See http://github.com/krosenvold/maven3 for a *lot* more details on problems issues and how to test this out on your builds. Looks incredibly promising ! I would be more than happy to give you test feedback if you could supply a binary dist with this feature. Or is it not yet ready to be tested by the 'masses' ? Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-3004/MNG-2802 - Achieving massive parallelity ?
It's getting close enough, as long as you satisfy the following constraints: - Make sure your build works with regular maven3 snapshots first ;) - You're not too reliant on snapshot artifacts (MNG-2802 is next on my TODO list now) - You're not generating source code in generate-sources - Running aggregating tasks (javadoc etc) is largely untested as of yet. The last two should be easily fixable but I've been concentrating on the main concurrency concerns (safe publication, deadlock avoidance etc) until now, but this seems to be rock solid with my build as of now. This is really also the stuff I need input on, since this is usually quite timing sensitive. (I have 2 different builds I run on C2D, i7 and dual xenons without hiccups right now) Get the install from http://cloud.github.com/downloads/krosenvold/maven3/apache-maven-3.0-SNAPSHOT-bin.tar.gz mvn -e -Dmaven.threads.experimental=6 clean install On my build, 1 thread per core gives best results. Maybe 3 for Core 2 duo. This version is up-to-date with maven3 trunk as of Thu Dec 3 09:01:44 2009 +0100. If you run without the -Dmaven.threads.experimental=6 option, you should basically by running regular maven3 trunk. Kristian On Thu, 2009-12-03 at 09:21 +0100, Jorg Heymans wrote: On Tue, Dec 1, 2009 at 9:49 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I am pleased to announce that the weave mode now does a mvn clean install of a fairly regular project with any number of threads, and at great speed improvement - 2-4x is not uncommon. There are still issues to be sorted out, and I'd be really grateful for any reports of problems. See http://github.com/krosenvold/maven3 for a *lot* more details on problems issues and how to test this out on your builds. Looks incredibly promising ! I would be more than happy to give you test feedback if you could supply a binary dist with this feature. Or is it not yet ready to be tested by the 'masses' ? Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jorg Heymans wrote: [ERROR] The project build-tools:1-SNAPSHOT (D:\src\myproject\pom.xml) has 1 error [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar - duplicate declaration of version 3.8.2 Shall i log an issue for this or is this a known feature ? The error itself is by design and is part of overall stricter POM validation. If the cause isn't present in the current POM, it must be present in one of its parents. mvn ... -e should tell more but I will look into improving the message for the next release. I can understand the need for stricter pom validation, but is it really necessary to fail a build completely just because a dependency is declared twice ? It seems a bit harsh. A big [WARNING] seems more appropriate. Will m3 also fail builds for this one then: [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! IMO most knowledgeable people react on warnings more positive, so more like ah cool m3 spotted a potential hazard so lets go and fix this instead of why the heck is m3 not able to build my project, lets revert to m2. Debatable, but that's how i see it. Cheers, Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
2009/12/3 Jorg Heymans jorg.heym...@gmail.com On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jorg Heymans wrote: [ERROR] The project build-tools:1-SNAPSHOT (D:\src\myproject\pom.xml) has 1 error [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar - duplicate declaration of version 3.8.2 Shall i log an issue for this or is this a known feature ? The error itself is by design and is part of overall stricter POM validation. If the cause isn't present in the current POM, it must be present in one of its parents. mvn ... -e should tell more but I will look into improving the message for the next release. I can understand the need for stricter pom validation, but is it really necessary to fail a build completely just because a dependency is declared twice ? It seems a bit harsh. Actually, I'm liking this build failing on double dependencies. A big [WARNING] seems more appropriate. Will m3 also fail builds for this one then: [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! IMO most knowledgeable people react on warnings more positive, so more like ah cool m3 spotted a potential hazard so lets go and fix this instead of why the heck is m3 not able to build my project, lets revert to m2. Debatable, but that's how i see it. Cheers, Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/12/3 Jorg Heymans jorg.heym...@gmail.com On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jorg Heymans wrote: [ERROR] The project build-tools:1-SNAPSHOT (D:\src\myproject\pom.xml) has 1 error [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar - duplicate declaration of version 3.8.2 Shall i log an issue for this or is this a known feature ? The error itself is by design and is part of overall stricter POM validation. If the cause isn't present in the current POM, it must be present in one of its parents. mvn ... -e should tell more but I will look into improving the message for the next release. I can understand the need for stricter pom validation, but is it really necessary to fail a build completely just because a dependency is declared twice ? It seems a bit harsh. Actually, I'm liking this build failing on double dependencies. Any particular reason or do you get a kick out of scanning 60+ module reactor builds for duplicates ? :-P Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
2009/12/3 Jorg Heymans jorg.heym...@gmail.com On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/12/3 Jorg Heymans jorg.heym...@gmail.com On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jorg Heymans wrote: [ERROR] The project build-tools:1-SNAPSHOT (D:\src\myproject\pom.xml) has 1 error [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar - duplicate declaration of version 3.8.2 Shall i log an issue for this or is this a known feature ? The error itself is by design and is part of overall stricter POM validation. If the cause isn't present in the current POM, it must be present in one of its parents. mvn ... -e should tell more but I will look into improving the message for the next release. I can understand the need for stricter pom validation, but is it really necessary to fail a build completely just because a dependency is declared twice ? It seems a bit harsh. Actually, I'm liking this build failing on double dependencies. Any particular reason or do you get a kick out of scanning 60+ module reactor builds for duplicates ? :-P I've got most of my projects down to no duplicates... the error stops it happening again! Perhaps we should have 2.2.2 start issuing the warning though! Or maybe a CLI option for 3.0 such as --no-strict-pom-validation Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-alpha-5
2009/12/3 Stephen Connolly stephen.alan.conno...@gmail.com 2009/12/3 Jorg Heymans jorg.heym...@gmail.com On Thu, Dec 3, 2009 at 11:10 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/12/3 Jorg Heymans jorg.heym...@gmail.com On Tue, Nov 24, 2009 at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jorg Heymans wrote: [ERROR] The project build-tools:1-SNAPSHOT (D:\src\myproject\pom.xml) has 1 error [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar - duplicate declaration of version 3.8.2 Shall i log an issue for this or is this a known feature ? The error itself is by design and is part of overall stricter POM validation. If the cause isn't present in the current POM, it must be present in one of its parents. mvn ... -e should tell more but I will look into improving the message for the next release. I can understand the need for stricter pom validation, but is it really necessary to fail a build completely just because a dependency is declared twice ? It seems a bit harsh. Actually, I'm liking this build failing on double dependencies. Any particular reason or do you get a kick out of scanning 60+ module reactor builds for duplicates ? :-P I've got most of my projects down to no duplicates... the error stops it happening again! Perhaps we should have 2.2.2 start issuing the warning though! Or maybe a CLI option for 3.0 such as --no-strict-pom-validation actually much better is something like --yes-i-am-a-bold-developer-and-i-know-i-should-remove-duplicate-dependencies-but-give-me-a-break that way you're _encouraged_ to fix it fast ;-) Jorg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Upload Apache Pivot artifacts to central repository?
Forwarding this message to dev@maven.apache.org in case us...@maven.apache.org wasn't the right place. Also, since sending the original message, I have heard that the document I had been referring to might be outdated. Can anyone help? Thanks! Greg Begin forwarded message: From: Greg Brown gkbr...@mac.com Date: December 2, 2009 12:38:13 PM EST To: us...@maven.apache.org Cc: pivot-...@incubator.apache.org Subject: Upload Apache Pivot artifacts to central repository Reply-To: pivot-...@incubator.apache.org Hi all, Apache Pivot is preparing for graduation, and we would like to upload our next set of release artifacts to the central Maven repository. We don't currently use Maven as a build tool, so I have been trying to follow the manual upload instructions listed here: http://www.apache.org/dev/release-publishing.html#maven-repo There is a section at the bottom that is meant to explain how to create an appropriate POM file, but it does not appear to be complete: http://www.apache.org/dev/release-publishing.html#repository-descriptor I have created some POMs that I think should work, but it would be very helpful if someone with a knowledgeable eye could take a quick look to make sure that they contain the correct information, are structured properly, etc. There is a root POM in the trunk, and a POM in each project-specific subdirectory that we plan to publish to the repository (note that these files refer to the anticipated future name and location of the project, as opposed to its current Incubator name and location): http://svn.apache.org/repos/asf/incubator/pivot/trunk/ Based on the documentation I have read thus far, I assume that we'll want to place our compiled JARs in a pivot/jars directory, and structure our POMs as follows: pivot/poms pom.xml /core/pom.xml /web/pom.xml /wtk/pom.xml /wtk-terra/pom.xml I don't think we'll need to use the distributions directory, and I assume that the licenses directory should simply contain a copy of our main LICENSE file. Is this all correct? Also, one of our mentors, Martijn Dashorst, suggested that there might be a top-level ASF POM that the root Pivot POM could extend (rather than duplicating the ASF info). If so, could you point us to it? Thanks - your assistance is very much appreciated! Greg Brown Apache Pivot
Re: Upload Apache Pivot artifacts to central repository?
Hi Greg, I'll take a look later today and ping back on the pivot dev list with what I find. On Thu, Dec 3, 2009 at 6:44 AM, Greg Brown gkbr...@mac.com wrote: Forwarding this message to dev@maven.apache.org in case us...@maven.apache.org wasn't the right place. Also, since sending the original message, I have heard that the document I had been referring to might be outdated. Can anyone help? Thanks! Greg Begin forwarded message: From: Greg Brown gkbr...@mac.com Date: December 2, 2009 12:38:13 PM EST To: us...@maven.apache.org Cc: pivot-...@incubator.apache.org Subject: Upload Apache Pivot artifacts to central repository Reply-To: pivot-...@incubator.apache.org Hi all, Apache Pivot is preparing for graduation, and we would like to upload our next set of release artifacts to the central Maven repository. We don't currently use Maven as a build tool, so I have been trying to follow the manual upload instructions listed here: http://www.apache.org/dev/release-publishing.html#maven-repo There is a section at the bottom that is meant to explain how to create an appropriate POM file, but it does not appear to be complete: http://www.apache.org/dev/release-publishing.html#repository-descriptor I have created some POMs that I think should work, but it would be very helpful if someone with a knowledgeable eye could take a quick look to make sure that they contain the correct information, are structured properly, etc. There is a root POM in the trunk, and a POM in each project-specific subdirectory that we plan to publish to the repository (note that these files refer to the anticipated future name and location of the project, as opposed to its current Incubator name and location): http://svn.apache.org/repos/asf/incubator/pivot/trunk/ Based on the documentation I have read thus far, I assume that we'll want to place our compiled JARs in a pivot/jars directory, and structure our POMs as follows: pivot/poms pom.xml /core/pom.xml /web/pom.xml /wtk/pom.xml /wtk-terra/pom.xml I don't think we'll need to use the distributions directory, and I assume that the licenses directory should simply contain a copy of our main LICENSE file. Is this all correct? Also, one of our mentors, Martijn Dashorst, suggested that there might be a top-level ASF POM that the root Pivot POM could extend (rather than duplicating the ASF info). If so, could you point us to it? Thanks - your assistance is very much appreciated! Greg Brown Apache Pivot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Doxia and Maven Doxia Site Tools version 1.1.2
+1 Vincent Siveton wrote: Hi, Following Dennis to get Maven Site Plugin 2.1 (we hope for Xmas), here is the release of Doxia 1.1.2. We solved around 20 issues for both: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=15517 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624styleName=Htmlversion=15518 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=1 Staging repos: https://repository.apache.org/content/repositories/maven-027/ Staging sites (need to sync): http://maven.apache.org/doxia/doxia-1.1.2 http://maven.apache.org/doxia/doxia-sitetools-1.1.2 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- 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 Doxia and Maven Doxia Site Tools version 1.1.2
+1 looks good. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Upload Apache Pivot artifacts to central repository?
Great, thanks! On Dec 3, 2009, at 11:27 AM, Brian Fox wrote: Hi Greg, I'll take a look later today and ping back on the pivot dev list with what I find. On Thu, Dec 3, 2009 at 6:44 AM, Greg Brown gkbr...@mac.com wrote: Forwarding this message to dev@maven.apache.org in case us...@maven.apache.org wasn't the right place. Also, since sending the original message, I have heard that the document I had been referring to might be outdated. Can anyone help? Thanks! Greg Begin forwarded message: From: Greg Brown gkbr...@mac.com Date: December 2, 2009 12:38:13 PM EST To: us...@maven.apache.org Cc: pivot-...@incubator.apache.org Subject: Upload Apache Pivot artifacts to central repository Reply-To: pivot-...@incubator.apache.org Hi all, Apache Pivot is preparing for graduation, and we would like to upload our next set of release artifacts to the central Maven repository. We don't currently use Maven as a build tool, so I have been trying to follow the manual upload instructions listed here: http://www.apache.org/dev/release-publishing.html#maven-repo There is a section at the bottom that is meant to explain how to create an appropriate POM file, but it does not appear to be complete: http://www.apache.org/dev/release-publishing.html#repository-descriptor I have created some POMs that I think should work, but it would be very helpful if someone with a knowledgeable eye could take a quick look to make sure that they contain the correct information, are structured properly, etc. There is a root POM in the trunk, and a POM in each project-specific subdirectory that we plan to publish to the repository (note that these files refer to the anticipated future name and location of the project, as opposed to its current Incubator name and location): http://svn.apache.org/repos/asf/incubator/pivot/trunk/ Based on the documentation I have read thus far, I assume that we'll want to place our compiled JARs in a pivot/jars directory, and structure our POMs as follows: pivot/poms pom.xml /core/pom.xml /web/pom.xml /wtk/pom.xml /wtk-terra/pom.xml I don't think we'll need to use the distributions directory, and I assume that the licenses directory should simply contain a copy of our main LICENSE file. Is this all correct? Also, one of our mentors, Martijn Dashorst, suggested that there might be a top-level ASF POM that the root Pivot POM could extend (rather than duplicating the ASF info). If so, could you point us to it? Thanks - your assistance is very much appreciated! Greg Brown Apache Pivot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Changes Plugin version 2.3
Dennis Lundberg wrote: This vote comes soon after the 2.2 release No need to apologize ;-) Staging repo: https://repository.apache.org/content/repositories/maven-036/ The .pom.asc seems not to match the plugin POM [0]. Looking at the POM, it seems as if it was deployed using Maven 2.1.0 and suffers from MNG-4167/MGPG-14. Benjamin [0] https://repository.apache.org/content/repositories/maven-036/org/apache/maven/plugins/maven-changes-plugin/2.3/maven-changes-plugin-2.3.pom - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (28 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 You may edit this subscription at: http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
