[GitHub] maven-surefire pull request: [SUREFIRE-1131] Remove obsolete maven...
GitHub user Tibor17 opened a pull request: https://github.com/apache/maven-surefire/pull/78 [SUREFIRE-1131] Remove obsolete maven profiles Remove maven profiles jdk1.3 and jdk 1.4. Inline testng dependency into ordinal dependencies from profile jdk15. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Tibor17/maven-surefire s1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/78.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #78 commit 3c662f89cc7005450e037f5f4210268320a494d6 Author: Tibor17 tibo...@lycos.com Date: 2014-12-28T09:13:03Z [SUREFIRE-1131] Remove obsolete maven profiles --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Hi, The vote has passed with the following result: +1 (binding): Karl Heinz Marbaise, Hervé Boutemy, Olivier Lamy, Kristian Rosenvold +1 (non binding): Andreas Gudian I will promote the artifacts to the central repo. Cheers Tibor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA
Swizzle sounds a good solution. I remember using it to migrate a mojo project to ASF instance. -- Olivier On 28 Dec 2014 17:14, Barrie Treloar baerr...@gmail.com wrote: On 28 December 2014 at 08:46, Jason van Zyl ja...@takari.io wrote: Would certainly be easier to have it at Apache at this point. I don't think it's particularly hard, just time consuming. I think the only safe option is exporting the entire database and removing all projects except ours. It will probably take several attempts and there are a lot of projects at Codehaus in that JIRA instance. I've tried moving individual projects with the RPC mechanism and generally doesn't work all that well. Perhaps someone who has done this before enough times if willing to step forward? Or can we lean on Atlassian?
Re: [VOTE] Release Apache Maven Plugin Testing version 3.3.0
Hi, here is only one vote missing ;-)... Kind regards Karl Heinz Marbaise On 12/18/14 2:40 AM, Igor Fedorenko wrote: Hi, We solved 1 issue: https://jira.codehaus.org/browse/MPLUGINTESTING-44 There are no issues left in JIRA Staging repo: https://repository.apache.org/content/repositories/maven-1106/ http://repository.apache.org/content/repositories/maven-1106/org/apache/maven/plugin-testing/maven-plugin-testing/3.3.0/maven-plugin-testing-3.3.0-source-release.zip Source release checksum(s): maven-plugin-testing-3.3.0-source-release.zip sha1: 323812b9b5ce00a247375f12c27f4f6019258089 Staging site: http://maven.apache.org/plugin-testing-archives/LATEST/ 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
[VOTE] Release Apache Maven EAR Plugin version 2.10
Hi, We solved 19 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132version=20436 http://jira.codehaus.org/issues/?jql=project%20%3D%20MEAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven- https://repository.apache.org/content/repositories/maven-/org/apache/maven/plugins/maven-ear-plugin/2.10/maven-ear-plugin-2.10-source-release.zip Source release checksum(s): maven-ear-plugin-2.10-source-release.zip sha1: 659e4b419d91d246b6b16329f4ade79bad74e53b Staging site: http://maven.apache.org/plugins-archives/maven-ear-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-surefire pull request: [SUREFIRE-1131] Remove obsolete maven...
Github user asfgit closed the pull request at: https://github.com/apache/maven-surefire/pull/78 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Plugin Testing version 3.3.0
+1 2014-12-28 15:06 GMT+01:00 Karl Heinz Marbaise khmarba...@gmx.de: Hi, here is only one vote missing ;-)... Kind regards Karl Heinz Marbaise On 12/18/14 2:40 AM, Igor Fedorenko wrote: Hi, We solved 1 issue: https://jira.codehaus.org/browse/MPLUGINTESTING-44 There are no issues left in JIRA Staging repo: https://repository.apache.org/content/repositories/maven-1106/ http://repository.apache.org/content/repositories/maven-1106/org/apache/maven/plugin-testing/maven-plugin-testing/3.3.0/maven-plugin-testing-3.3.0-source-release.zip Source release checksum(s): maven-plugin-testing-3.3.0-source-release.zip sha1: 323812b9b5ce00a247375f12c27f4f6019258089 Staging site: http://maven.apache.org/plugin-testing-archives/LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
I'll sumarize what appears to be our consensus so far. Update to jdk 6.0 at will, but please be sure that we're not leaving the last 1.5 version in a regressed state. Version number indicates minimum maven version, so a simple JDK upgrade only mandates a minor version update. We are also in a situation a lot of code will be migrating to 3.0.5 minimum real soon now. Based on past experience, I know that once we start moving shared code to 1.6, there's no turning back. So while it's certainly feasible to our users to release 3.x versions of our plugins with 1.5 code base, I think this model will not sustain for any amount time. So I still think the recommendation should be 1.6+ for the 3.x plugins, but 1.6 may also happen earlier and at RM's discretion. I really think we'd make things a lot easier for our users by declaring the whole 3.x range of plugins 1.6 only. But I have a feeling I'm overcomplicating the user perspective since most of them couldn't care less about 1.5 anyway. I believe that sums it up. We might want to make some kind of statement on this... ? (Does anyone really care about 1.5...?) Kristian 2014-12-27 18:28 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi Kristian, I am +1 for any Release Manager wanting to up the minimum Java version to 1.6 for any of our components, on one condition: if there are any bugs fixed since the last release of the component, then please do a final Java 5 compatible release of the component before moving it to Java 6. Regarding versioning I would very much like us to use the major version of plugins, and other components, to indicate the minimum *Maven* version it requires. So I'm fine with a bump of the minor version for a component wishing to switch to Java 6. A current example the highlights both of the above is the Checkstyle Plugin. We will be releasing version 2.14 of the plugin as the final Java 5 compatible version. After that we will release version 2.15 which will require a version of Checkstyle (the tool - not our plugin) that requires Java 6 making our plugin require Java 6 as well. We should also add an issue in JIRA for each component, specifically for the change in Java requirement. To make it easier for our users and ourselves it it also wise to add descriptions to the versions in JIRA. See the Checkstyle Plugin's road map for an example: http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold krosenv...@apache.org wrote: Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a source-level-shading, but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay forever on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com: I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven Surefire Plugin 2.18.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Surefire Plugin, version 2.18.1 The release contains a number of bug fixes. Again we received contributions from the community in form of bug reports and bug fixes. Thank you and keep them coming! http://maven.apache.org/plugins/maven-surefire-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.18.1/version /plugin or for failsafe: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.18.1/version /plugin or for surefire-report: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.18.1/version /plugin Release Notes - Maven Surefire - Version 2.18.1 ** Bug * [SUREFIRE-859] - Exception in thread TreadedStreamConsumer java.lang.RuntimeException during GC * [SUREFIRE-1036] - Tests using MockitoJUnitRunner are always run regardless of membership in specified group * [SUREFIRE-1112] - Remove uneccessary newlines in console output for test results with no error * [SUREFIRE-1114] - NPE in TestSetStats. Concurrency issue with parallel methods on TestNG. * [SUREFIRE-1117] - The documentation of re-run parameter should mention limitations with JUnit 4.xprovider * [SUREFIRE-1121] - java.lang.NullPointerException org.apache.maven.plugin.surefire.report.DefaultReporterFactory.mergeFromOtherFactories(DefaultReporterFactory.java:82) * [SUREFIRE-1122] - When running failsafe with -Dfailsafe.rerunFailingTestsCount and parallel all, the reports are not generated correctly ** Improvement * [SUREFIRE-987] - Provide user property for suiteXmlFile so that it can be passed from Maven Command line * [SUREFIRE-995] - Support searching superclass for JUnit @Category * [SUREFIRE-1109] - runOrder should have a user property * [SUREFIRE-1110] - Document the memory requirements to run unit- and integration tests for a release test * [SUREFIRE-1116] - Parallel Computer should use ConsoleLogger interface * [SUREFIRE-1120] - Improved warning message File encoding has not been set, ... Enjoy, -The Apache Maven team
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold kristian.rosenv...@gmail.com: I'll sumarize what appears to be our consensus so far. Update to jdk 6.0 at will, but please be sure that we're not leaving the last 1.5 version in a regressed state. Version number indicates minimum maven version, so a simple JDK upgrade only mandates a minor version update. We are also in a situation a lot of code will be migrating to 3.0.5 minimum real soon now. When talking about migrating plugins, we should make the plugins 3.0(.x) compatible, so we should use migrate to 3.0 (the lowest) and not 3.0.5 (the latest). Most important: for the plugins it doesn't matter; I'm not aware of any code where it makes any difference. This should give us enough space to remove all M2 hacks with reflections, etc. And this makes it a lot easier to communicate with the community by just saying: maven-plugins 3.x are compatible with all Maven3 distributions. Robert Based on past experience, I know that once we start moving shared code to 1.6, there's no turning back. So while it's certainly feasible to our users to release 3.x versions of our plugins with 1.5 code base, I think this model will not sustain for any amount time. So I still think the recommendation should be 1.6+ for the 3.x plugins, but 1.6 may also happen earlier and at RM's discretion. I really think we'd make things a lot easier for our users by declaring the whole 3.x range of plugins 1.6 only. But I have a feeling I'm overcomplicating the user perspective since most of them couldn't care less about 1.5 anyway. I believe that sums it up. We might want to make some kind of statement on this... ? (Does anyone really care about 1.5...?) Kristian 2014-12-27 18:28 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi Kristian, I am +1 for any Release Manager wanting to up the minimum Java version to 1.6 for any of our components, on one condition: if there are any bugs fixed since the last release of the component, then please do a final Java 5 compatible release of the component before moving it to Java 6. Regarding versioning I would very much like us to use the major version of plugins, and other components, to indicate the minimum *Maven* version it requires. So I'm fine with a bump of the minor version for a component wishing to switch to Java 6. A current example the highlights both of the above is the Checkstyle Plugin. We will be releasing version 2.14 of the plugin as the final Java 5 compatible version. After that we will release version 2.15 which will require a version of Checkstyle (the tool - not our plugin) that requires Java 6 making our plugin require Java 6 as well. We should also add an issue in JIRA for each component, specifically for the change in Java requirement. To make it easier for our users and ourselves it it also wise to add descriptions to the versions in JIRA. See the Checkstyle Plugin's road map for an example: http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold krosenv...@apache.org wrote: Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a source-level-shading, but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay forever on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and critical stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies bimargul...@gmail.com: I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - 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: Releases, Continuous Delivery and the Future
On Dec 14, 2014, at 8:29 PM, Jason van Zyl ja...@takari.io wrote: What we want is a form of continuous delivery where a version like 3.2.4 is the version that we call it to the outside world (some refer to it as the marketing version) and the qualifier changes from build to build so we have: 3.2.4-qualifier And for simplicity's sake let's just say the qualifier is a build number so we end up with: 3.2.4-01 3.2.4-02 ... 3.2.4-NN +1 This really the only viable scheme I've seen used over the years. It's how we do it at Sonatype and it's never been an issue that the public version is shown with some -build number. We will want to ensure that only one release version gets published though to reduce confusion. Since everything is staged, this should happen normally. For plugins, which are commonly referred to by users in their poms, this might turn out to be a problem as it increases the maintenance load but I think we start trying it and if there is an issue we go to an alternate approach. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Le dimanche 28 décembre 2014 21:04:50 Robert Scholte a écrit : Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold kristian.rosenv...@gmail.com: I'll sumarize what appears to be our consensus so far. Update to jdk 6.0 at will, but please be sure that we're not leaving the last 1.5 version in a regressed state. Version number indicates minimum maven version, so a simple JDK upgrade only mandates a minor version update. We are also in a situation a lot of code will be migrating to 3.0.5 minimum real soon now. When talking about migrating plugins, we should make the plugins 3.0(.x) compatible, so we should use migrate to 3.0 (the lowest) and not 3.0.5 (the latest). Most important: for the plugins it doesn't matter; I'm not aware of any code where it makes any difference. This should give us enough space to remove all M2 hacks with reflections, etc. And this makes it a lot easier to communicate with the community by just saying: maven-plugins 3.x are compatible with all Maven3 distributions. +1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA
infra@ asks: _exactly_ how many projects. Does anyone know off hand? On Sun, Dec 28, 2014 at 1:13 AM, Barrie Treloar baerr...@gmail.com wrote: On 28 December 2014 at 08:46, Jason van Zyl ja...@takari.io wrote: Would certainly be easier to have it at Apache at this point. I don't think it's particularly hard, just time consuming. I think the only safe option is exporting the entire database and removing all projects except ours. It will probably take several attempts and there are a lot of projects at Codehaus in that JIRA instance. I've tried moving individual projects with the RPC mechanism and generally doesn't work all that well. Perhaps someone who has done this before enough times if willing to step forward? Or can we lean on Atlassian? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA projects for Maven
On Sun, Dec 28, 2014 at 6:07 PM, Jake Farrell jfarr...@apache.org wrote: Hey Benson What is the exact number and would an import of existing issues be needed or will the project be taking care of that migration? I did a count and came up with 46. I've asked for help in rendering that number precise. The Maven dev list is currently mulling over the technology of migration; if we can come up with a way to do it for ourselves, I think we're willing. At one extreme, there was some discussion of working at the SQL level, which, I think, would at least involve collaboration. Can all the maven jira projects share a common group of project admins, contributors, etc or is each unique? I believe that the answer is that they will all club together. All the Maven plugins are products of the Maven PMC, we don't have any fine-grained access control for anything else, so I don't see why we'd need it for JIRA. Do all the notifications for each project go to the same mailing list? Ditto here, but, I've added dev@maven to this thread so that others can participate. Thanks -Jake On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies bimargul...@gmail.com wrote: Dear Infra, For historical reasons, the Maven project has a host of JIRA projects at codehaus. This is not an ideal situation for many reasons. In the past, discussions on moving onto ASF infrastructure have founded on the sheer number: dozens. Infrastructure didn't feel that they could support that many project, and the Maven project felt that it would be very difficult to combine all of the many per-maven-plugin JIRA projects into a single project with many components. It seems to me that much has changed since the last time that this subject was explored, so I felt that it was worth re-opening the discussion. Could the existing main JIRA support a large influx of low-activity projects? Or would infra consider a separate instance? Thanks, benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA
if I count from http://jira.codehaus.org/secure/BrowseProjects.jspa#all taking relevant projects from Maven 2 Plugins, Maven Admin and Maven Technologies categories, I get 61 projects Hope this helps :) Regards, Hervé Le dimanche 28 décembre 2014 18:13:45 Benson Margulies a écrit : infra@ asks: _exactly_ how many projects. Does anyone know off hand? On Sun, Dec 28, 2014 at 1:13 AM, Barrie Treloar baerr...@gmail.com wrote: On 28 December 2014 at 08:46, Jason van Zyl ja...@takari.io wrote: Would certainly be easier to have it at Apache at this point. I don't think it's particularly hard, just time consuming. I think the only safe option is exporting the entire database and removing all projects except ours. It will probably take several attempts and there are a lot of projects at Codehaus in that JIRA instance. I've tried moving individual projects with the RPC mechanism and generally doesn't work all that well. Perhaps someone who has done this before enough times if willing to step forward? Or can we lean on Atlassian? - 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: JIRA projects for Maven
A more patient counter than I reports: if I count from http://jira.codehaus.org/secure/BrowseProjects.jspa#all taking relevant projects from Maven 2 Plugins, Maven Admin and Maven Technologies categories, I get 61 projects On Sun, Dec 28, 2014 at 6:20 PM, Benson Margulies bimargul...@gmail.com wrote: On Sun, Dec 28, 2014 at 6:07 PM, Jake Farrell jfarr...@apache.org wrote: Hey Benson What is the exact number and would an import of existing issues be needed or will the project be taking care of that migration? I did a count and came up with 46. I've asked for help in rendering that number precise. The Maven dev list is currently mulling over the technology of migration; if we can come up with a way to do it for ourselves, I think we're willing. At one extreme, there was some discussion of working at the SQL level, which, I think, would at least involve collaboration. Can all the maven jira projects share a common group of project admins, contributors, etc or is each unique? I believe that the answer is that they will all club together. All the Maven plugins are products of the Maven PMC, we don't have any fine-grained access control for anything else, so I don't see why we'd need it for JIRA. Do all the notifications for each project go to the same mailing list? Ditto here, but, I've added dev@maven to this thread so that others can participate. Thanks -Jake On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies bimargul...@gmail.com wrote: Dear Infra, For historical reasons, the Maven project has a host of JIRA projects at codehaus. This is not an ideal situation for many reasons. In the past, discussions on moving onto ASF infrastructure have founded on the sheer number: dozens. Infrastructure didn't feel that they could support that many project, and the Maven project felt that it would be very difficult to combine all of the many per-maven-plugin JIRA projects into a single project with many components. It seems to me that much has changed since the last time that this subject was explored, so I felt that it was worth re-opening the discussion. Could the existing main JIRA support a large influx of low-activity projects? Or would infra consider a separate instance? Thanks, benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: JIRA
-Original Message- From: Hervé BOUTEMY Sent: Sunday, December 28, 2014 18:27 if I count from http://jira.codehaus.org/secure/BrowseProjects.jspa#all taking relevant projects from Maven 2 Plugins, Maven Admin and Maven Technologies categories, I get 61 projects I just got 244. 83 Maven 1 Plugins 114 Maven 2 Plugins 6 Maven Admin 26 Maven Technologies 15 No Category (GMAVENPLUS, MNGIDEA, MTOMCAT, MVNBLAME, MVNCONFSITE, MAVENENTERPRISE, PSEUDOTRANS, MDWEB, MDBUNIT, MWEBLOGIC, MOPENJPA, MSITESKIN, MTRUEZIP, MUNIX, UMP) Hope this helps :) Regards, Hervé Le dimanche 28 décembre 2014 18:13:45 Benson Margulies a écrit : infra@ asks: _exactly_ how many projects. Does anyone know off hand? On Sun, Dec 28, 2014 at 1:13 AM, Barrie Treloar baerr...@gmail.com wrote: On 28 December 2014 at 08:46, Jason van Zyl ja...@takari.io wrote: Would certainly be easier to have it at Apache at this point. I don't think it's particularly hard, just time consuming. I think the only safe option is exporting the entire database and removing all projects except ours. It will probably take several attempts and there are a lot of projects at Codehaus in that JIRA instance. I've tried moving individual projects with the RPC mechanism and generally doesn't work all that well. Perhaps someone who has done this before enough times if willing to step forward? Or can we lean on Atlassian? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [2/2] maven-wagon git commit: Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/maven-wagon
Obviously, I am Git newbie, not sure if this causes problem? -D On Sun, Dec 28, 2014 at 3:55 PM, dant...@apache.org wrote: Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/maven-wagon Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo Commit: http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/94dd5f14 Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/94dd5f14 Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/94dd5f14 Branch: refs/heads/master Commit: 94dd5f14e7be3a4293249091698227908c9701d0 Parents: 584dd9f dd623e8 Author: dantran dant...@gmail.com Authored: Sun Dec 28 15:55:23 2014 -0800 Committer: dantran dant...@gmail.com Committed: Sun Dec 28 15:55:23 2014 -0800 -- --
Re: JIRA projects for Maven
On Sun, Dec 28, 2014 at 9:18 PM, David Nalley da...@gnsa.us wrote: On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies bimargul...@gmail.com wrote: Dear Infra, For historical reasons, the Maven project has a host of JIRA projects at codehaus. This is not an ideal situation for many reasons. In the past, discussions on moving onto ASF infrastructure have founded on the sheer number: dozens. Infrastructure didn't feel that they could support that many project, and the Maven project felt that it would be very difficult to combine all of the many per-maven-plugin JIRA projects into a single project with many components. Can you tell me why it would be difficult? E.g. I am envisioning a single maven project, an each plugin has a component instead of a separate project. David, I've restored dev@maven to this thread. I suspect that others may be more eloquent than I on this; if no one else joins in, I'll expand tomorrow some time. It seems to me that much has changed since the last time that this subject was explored, so I felt that it was worth re-opening the discussion. Could the existing main JIRA support a large influx of low-activity projects? Or would infra consider a separate instance? The number of projects is not a huge issue. Jira can support many magnitudes more 'projects' than we currently have. Migrating 61 low-activity projects seems like a lot of work; historically, that's involved dumping to XML, potentially deploying to a matching version of the source, and then upgrading the version to match the destination version of Jira, then exporting again and deploying to the destination version. Generally (depending on the way the restore happens) the ticket numbers may not stay the same. Historically, we've had a lot of frustration on this front when we've attempted migrations. Though generally they tend to be larger migrations. That said, how much of this work is Maven willing to bear? --David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: JIRA projects for Maven
-Original Message- From: Benson Margulies Sent: Sunday, December 28, 2014 21:52 On Sun, Dec 28, 2014 at 9:18 PM, David Nalley da...@gnsa.us wrote: On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies bimargul...@gmail.com wrote: Dear Infra, For historical reasons, the Maven project has a host of JIRA projects at codehaus. This is not an ideal situation for many reasons. In the past, discussions on moving onto ASF infrastructure have founded on the sheer number: dozens. Infrastructure didn't feel that they could support that many project, and the Maven project felt that it would be very difficult to combine all of the many per-maven-plugin JIRA projects into a single project with many components. Can you tell me why it would be difficult? E.g. I am envisioning a single maven project, an each plugin has a component instead of a separate project. David, I've restored dev@maven to this thread. I suspect that others may be more eloquent than I on this; if no one else joins in, I'll expand tomorrow some time. It seems to me that much has changed since the last time that this subject was explored, so I felt that it was worth re-opening the discussion. Could the existing main JIRA support a large influx of low-activity projects? Or would infra consider a separate instance? The number of projects is not a huge issue. Jira can support many magnitudes more 'projects' than we currently have. Migrating 61 low-activity projects seems like a lot of work; historically, that's involved dumping to XML, potentially deploying to a matching version of the source, and then upgrading the version to match the destination version of Jira, then exporting again and deploying to the destination version. Generally (depending on the way the restore happens) the ticket numbers may not stay the same. Historically, we've had a lot of frustration on this front when we've attempted migrations. Though generally they tend to be larger migrations. That said, how much of this work is Maven willing to bear? --David I have some spare cycles right now to tackle this. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
3.2.3 not available though http://archive.apache.org/dist/maven/binaries/ ?
Hello, for some reason 3.2.3 is not available in the archives, is that intentional or something went wrong with the 3.2.5 release? Thanks Milos
Re: JIRA projects for Maven
Le dimanche 28 décembre 2014 21:18:18 David Nalley a écrit : On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies bimargul...@gmail.com wrote: Dear Infra, For historical reasons, the Maven project has a host of JIRA projects at codehaus. This is not an ideal situation for many reasons. In the past, discussions on moving onto ASF infrastructure have founded on the sheer number: dozens. Infrastructure didn't feel that they could support that many project, and the Maven project felt that it would be very difficult to combine all of the many per-maven-plugin JIRA projects into a single project with many components. Can you tell me why it would be difficult? E.g. I am envisioning a single maven project, an each plugin has a component instead of a separate project. we use such a schema for parent POMS at ASF with success: 4 components [1] we do the same for shared components at Codehaus, and it's a nightmare: 30 components [2], with a dedicated roadmap/changelog for each for plugins, we have 1 Jira project for each of our ~45 plugins (see issue tracking column on [3]), with components for internal details (no roadmap or changelog per component here, see Jira project for plugin or site or dependency) Clearly, changing plugins Jira model to shared components Jira model would not fit: even more plugins than shared components, and we would loose Jira components as plugin-internal structure The question for the PMC would more be: what if we could split shared components into smaller Jira projects? It seems to me that much has changed since the last time that this subject was explored, so I felt that it was worth re-opening the discussion. Could the existing main JIRA support a large influx of low-activity projects? Or would infra consider a separate instance? The number of projects is not a huge issue. Jira can support many magnitudes more 'projects' than we currently have. Migrating 61 low-activity projects seems like a lot of work; historically, that's involved dumping to XML, potentially deploying to a matching version of the source, and then upgrading the version to match the destination version of Jira, then exporting again and deploying to the destination version. Generally (depending on the way the restore happens) the ticket numbers may not stay the same. the ticket IDs or the ticket count? changing ticket IDs would be a pain, since it is used in scm comments to track details Historically, we've had a lot of frustration on this front when we've attempted migrations. Though generally they tend to be larger migrations. That said, how much of this work is Maven willing to bear? as much as possible if we can do it Jira project per Jira project: each migration could be done when a release is done We just need to learn how to do both on Codehaus and on ASF sides: have a few key people on the PMC who will help the others do the job Jira project per Jira project over time. I'm sure we can get a few volunteers, wanting to help and learn some Jira admin. Regards, Hervé --David [1] https://issues.apache.org/jira/browse/MPOM/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel [2] http://jira.codehaus.org/browse/MSHARED#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel [3] http://maven.apache.org/plugins/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [2/2] maven-wagon git commit: Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/maven-wagon
yes, that's one of the first git trick to learn: git rebase [1] :) perhaps real git gurus here have better links to explain. Regards, Hervé [1] https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase Le dimanche 28 décembre 2014 16:09:31 Dan Tran a écrit : Obviously, I am Git newbie, not sure if this causes problem? -D On Sun, Dec 28, 2014 at 3:55 PM, dant...@apache.org wrote: Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/maven-wagon Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo Commit: http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/94dd5f14 Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/94dd5f14 Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/94dd5f14 Branch: refs/heads/master Commit: 94dd5f14e7be3a4293249091698227908c9701d0 Parents: 584dd9f dd623e8 Author: dantran dant...@gmail.com Authored: Sun Dec 28 15:55:23 2014 -0800 Committer: dantran dant...@gmail.com Committed: Sun Dec 28 15:55:23 2014 -0800 -- -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.2.3 not available though http://archive.apache.org/dist/maven/binaries/?
we generally switched Maven release canonical download area to https://dist.apache.org/repos/dist/release/maven/maven-3/ IIRC, http://archive.apache.org/dist/maven/binaries/ was used by Jenkins folks for automatic Maven version discovery and download, before the change seems like we didn't took the effort to copy latest releases to this legacy location is this legacy location still useful? notice we should add a HEADER or README in the legacy directory to explain the story Regards, Hervé Le lundi 29 décembre 2014 16:51:07 Milos Kleint a écrit : Hello, for some reason 3.2.3 is not available in the archives, is that intentional or something went wrong with the 3.2.5 release? Thanks Milos - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.2.3 not available though http://archive.apache.org/dist/maven/binaries/ ?
Why do you need it there? The way binaries are kept at Apache is inconsistent. How it evolved over time where things disappear from one place to another (official distribution to archives) I don't find makes much sense but that's the way it is. If you require a distribution in a standard place take it from Maven Central. It will always be in the same place. On Dec 29, 2014, at 12:51 AM, Milos Kleint mkle...@gmail.com wrote: Hello, for some reason 3.2.3 is not available in the archives, is that intentional or something went wrong with the 3.2.5 release? Thanks Milos Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
