Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
+1 2011/7/30 Dennis Lundberg denn...@apache.org: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend : http://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
upgrade plugins to plugin parent 21
Hi! Most of our plugins have an old parent 20 or 19. maven-acr-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-ant-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-antrun-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-assembly-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-changelog-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-clean-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-compiler-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-deploy-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-doap-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-docck-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-ear-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-ejb-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-gpg-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-help-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-idea-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-install-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-invoker-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-jarsigner-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-javadoc-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-linkcheck-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-one-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-patch-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-pmd-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-project-info-reports-plugin/pom.xml: artifactIdmaven-plugins/artifactId maven-rar-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-reactor-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-remote-resources-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-repository-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-resources-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-shade-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-source-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-stage-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-toolchains-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-verifier-plugin/pom.xml:artifactIdmaven-plugins/artifactId maven-war-plugin/pom.xml:artifactIdmaven-plugins/artifactId I'll go on and upgrade them gradually to version 21 now. Doing local IT runs of course. LieGrue, strub - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
more symlink failures on Jenkins
I committed a fix for MNG-3951's test case that stopped it breaking on Mac (and passed the first Jenkins ubuntu run). A later build threw up this: https://builds.apache.org/job/core-integration-testing-maven-3-trunk-jdk-1.6/7/testReport/ It's full of path related issues, but my change didn't touch any Maven code or other test cases. Is anyone familiar with what was previously broken here able to shed any light before I take a closer look? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: more symlink failures on Jenkins
Looks like they pass on ubuntu1 but fail on ubuntu3 - I'd guess that /home/jenkins is a symlink on ubuntu3 but not on ubuntu1, and that something in the tests is resolving the symlink on one side but not resolving it on the other. Just a guess, from the Jenkins side of things. A. On Mon, Aug 1, 2011 at 3:22 PM, Brett Porter br...@apache.org wrote: I committed a fix for MNG-3951's test case that stopped it breaking on Mac (and passed the first Jenkins ubuntu run). A later build threw up this: https://builds.apache.org/job/core-integration-testing-maven-3-trunk-jdk-1.6/7/testReport/ It's full of path related issues, but my change didn't touch any Maven code or other test cases. Is anyone familiar with what was previously broken here able to shed any light before I take a closer look? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2/3 and Cobetura plugin with both TestNG and JUnit tests (with Surefire plugin configuration)
On Thu, Jul 28, 2011 at 6:04 AM, Martin Gainty mgai...@hotmail.com wrote:
Larry-
try loading both dependencies in your local repository and running offline
with mvn -o (at least your dependencies will be found)
did you check cobertura for errors?
mvn -e -X cobertura:cobertura -Dquiet=true
I did not see any obvious errors.
take junit out of the mix and run testng as solo Test dependency then check
output folders
${project.reporting.outputDirectory}/cobertura.
if these tests fail you may have found a bug in which cause you need to file
a JIRA at
http://jira.codehaus.org/browse/MCOBERTURA
I want to run with both JUnit and TestNG. By removing JUnit (and the
tests that JUnit run), it ran just fine, as do the inverse, just JUnit
and no TestNG. It is the combination of both of them.
To help, instead of having gists, I created a github project:
https://github.com/larrys/CoverageBug which you can fetch and run
locally and see exactly what I'm talking about and be able to possibly
tweak or debug any issues that I lack the knowledge to do.
Thanks
-- Larry
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: more symlink failures on Jenkins
Yup, that was it. I've fixed it for those tests, and it seems to be ok now. All things going well it may make sense to have the verifier return the extracted resources as a canonical path so it's consistent across test cases, since that's what ends up being compared against from maven. - Brett On 02/08/2011, at 1:51 AM, Andrew Bayer wrote: Looks like they pass on ubuntu1 but fail on ubuntu3 - I'd guess that /home/jenkins is a symlink on ubuntu3 but not on ubuntu1, and that something in the tests is resolving the symlink on one side but not resolving it on the other. Just a guess, from the Jenkins side of things. A. On Mon, Aug 1, 2011 at 3:22 PM, Brett Porter br...@apache.org wrote: I committed a fix for MNG-3951's test case that stopped it breaking on Mac (and passed the first Jenkins ubuntu run). A later build threw up this: https://builds.apache.org/job/core-integration-testing-maven-3-trunk-jdk-1.6/7/testReport/ It's full of path related issues, but my change didn't touch any Maven code or other test cases. Is anyone familiar with what was previously broken here able to shed any light before I take a closer look? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
+1 Vincent 2011/7/30 Dennis Lundberg denn...@apache.org: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- 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
Re: Build failed in Jenkins: core-integration-testing-maven-3-trunk-windows #9
I suspected this was a problem with the length of the path. Seems to be working after wiping out the working copy, in case anyone else stumbles onto it. The next problem was the -Dmaven.home property not escaping properly. I removed the maven.repo.local as it was duplicated (thanks to the private local repository being enabled), and moved it to the goals line instead of properties section. Filed a Jenkins bug as a result: https://issues.jenkins-ci.org/browse/JENKINS-10539 I got it down to one test failure - MavenITmng3710PollutedClonedPluginsTest, maybe someone on Windows can confirm if that is unique to the CI or not. - Brett On 02/08/2011, at 12:06 AM, Apache Jenkins Server wrote: See https://builds.apache.org/job/core-integration-testing-maven-3-trunk-windows/9/changes [INFO] [INFO] [INFO] Building Maven IT Plugin :: Parameter Implementation 2.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ maven-it-plugin-parameter-implementation --- [INFO] Deleting F:\hudson\hudson-slave\workspace\core-integration-testing-maven-3-trunk-windows\core-integration-testing-trunk\core-it-support\core-it-plugins\maven-it-plugin-parameter-implementation\target [INFO] [INFO] --- maven-plugin-plugin:2.8:descriptor (default-descriptor) @ maven-it-plugin-parameter-implementation --- [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] Applying mojo extractor for language: java [INFO] Mojo extractor for language: java found 0 mojo descriptors. [INFO] Applying mojo extractor for language: bsh [INFO] Mojo extractor for language: bsh found 0 mojo descriptors. ... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:2.8:descriptor (default-descriptor) on project maven-it-plugin-parameter-implementation: Error extracting plugin descriptor: 'No mojo definitions were found for plugin: org.apache.maven.its.plugins:maven-it-plugin-parameter-implementation.' - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn goals -rf :maven-it-plugin-parameter-implementation Recording test results -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Build failed in Jenkins: core-integration-testing-maven-3-trunk-windows #9
On 02/08/2011, at 4:03 AM, Brett Porter wrote: I suspected this was a problem with the length of the path. Seems to be working after wiping out the working copy, in case anyone else stumbles onto it. The next problem was the -Dmaven.home property not escaping properly. I removed the maven.repo.local as it was duplicated (thanks to the private local repository being enabled), and moved it to the goals line instead of properties section. Filed a Jenkins bug as a result: https://issues.jenkins-ci.org/browse/JENKINS-10539 I got it down to one test failure - MavenITmng3710PollutedClonedPluginsTest, maybe someone on Windows can confirm if that is unique to the CI or not. Actually: F:\hudson\hudson-slave\workspace\core-integration-testing-maven-3-trunk-windows\core-integration-testing-trunk\core-it-suite\target\test-classes\mng-3710\original-model\plugins\maven-mng3710-directInvoke-plugin\target\surefire\surefirebooter6661236544958895647.jar That is probably too long for Windows. Anyone want to take a stab at shortening it? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[DISCUSS] Project local setting.xml
I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Project local setting.xml
hasn't that been the purpose of profiles.xml files back in 2.x before it was removed for 3.x? Milos On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier pg...@redhat.com wrote: I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - 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] Project local setting.xml
What is the point of putting a settings.xml in your SCM next to your pom.xml? In this case just add the repos in the root pom. ++ Julien - Mail original - De : Milos Kleint mkle...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Lundi 1 Août 2011 21h02 Objet : Re: [DISCUSS] Project local setting.xml hasn't that been the purpose of profiles.xml files back in 2.x before it was removed for 3.x? Milos On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier pg...@redhat.com wrote: I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins is sending more e-mails now
Hi, We should use the Editable Email Notification instead of the E-mail Notification . The default one is very badly done for Maven projects and will spam you for each errorneous/fixed module. The Editable is more powerful and will notify you only once per job. FYI, the Jenkins team was working recently into merging a part of the Editable Email feature into the default one. Cheers, Arnaud On Sun, Jul 31, 2011 at 11:03 PM, Dennis Lundberg denn...@apache.orgwrote: Hi Just a heads up that those of you that are subscribed to notificati...@maven.apache.org will be seeing a lot more e-mails coming your way from Jenkins. I'm going over the configurations for our projects in Jenkins, one parameter at a time. This time I've enabled e-mail notifications for pretty much all of our builds. They are all configured to be sent to notificati...@maven.apache.org, so those of you that are interested in getting direct feedback on how healthy our builds are, now is the time to subscribe. I've also added a JDK 1.7 build of core-integration-testing+maven-3, which passes :-) -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Build failed in Jenkins: core-integration-testing-maven-3-trunk-windows #9
On 2011-08-01 20:06, Brett Porter wrote: On 02/08/2011, at 4:03 AM, Brett Porter wrote: I suspected this was a problem with the length of the path. Seems to be working after wiping out the working copy, in case anyone else stumbles onto it. The next problem was the -Dmaven.home property not escaping properly. I removed the maven.repo.local as it was duplicated (thanks to the private local repository being enabled), and moved it to the goals line instead of properties section. Filed a Jenkins bug as a result: https://issues.jenkins-ci.org/browse/JENKINS-10539 I got it down to one test failure - MavenITmng3710PollutedClonedPluginsTest, maybe someone on Windows can confirm if that is unique to the CI or not. Actually: F:\hudson\hudson-slave\workspace\core-integration-testing-maven-3-trunk-windows\core-integration-testing-trunk\core-it-suite\target\test-classes\mng-3710\original-model\plugins\maven-mng3710-directInvoke-plugin\target\surefire\surefirebooter6661236544958895647.jar That is probably too long for Windows. Anyone want to take a stab at shortening it? The latest build passed in Jenkins, but I have shortened the job names a bit by dropping -trunk from them. All CI builds are on trunk anyway, unless otherwise stated. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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: [DISCUSS] Project local setting.xml
Using a project local settings allows you to use the repo during build, but still have a clean pom in the repo when you release. We've experienced a lot of problems related to repos in the poms. On 08/01/2011 02:16 PM, Julien HENRY wrote: What is the point of putting a settings.xml in your SCM next to your pom.xml? In this case just add the repos in the root pom. ++ Julien - Mail original - De : Milos Kleint mkle...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Lundi 1 Août 2011 21h02 Objet : Re: [DISCUSS] Project local setting.xml hasn't that been the purpose of profiles.xml files back in 2.x before it was removed for 3.x? Milos On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier pg...@redhat.com wrote: I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Project local setting.xml
I guess one really nice effect of this would allow you to define a certain internal-only environment for project developers to use, that won't pollute the POM once it's in the remote repository... But what about people checking out your project and trying to build it if they don't have access to the things in your project-local settings.xml though? This is a problem inherent with system-scoped dependencies, and part of why they're such a mess to deal with. Maybe it's worth giving people enough rope to hang themselves, and trusting them to be responsible. I suppose profiles.xml was a way to do exactly this too...what was the original reasoning behind removing support for it, does anyone remember? -john On 8/1/11 3:16 PM, Julien HENRY wrote: What is the point of putting a settings.xml in your SCM next to your pom.xml? In this case just add the repos in the root pom. ++ Julien - Mail original - De : Milos Kleintmkle...@gmail.com À : Maven Developers Listdev@maven.apache.org Cc : Envoyé le : Lundi 1 Août 2011 21h02 Objet : Re: [DISCUSS] Project local setting.xml hasn't that been the purpose of profiles.xml files back in 2.x before it was removed for 3.x? Milos On Mon, Aug 1, 2011 at 9:00 PM, Paul Gierpg...@redhat.com wrote: I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Project local setting.xml
I have several alternative design ideas. 0) If you religiously use a repository manager and mirrorOf *, you can prevent this rogues from bothering you. 1) How about if the release / deploy process had an option to remove repositories from the POM? 2) Let's design and implement basic repository redirection in maven itself, so that people don't have to set up an entire repo-man to compensate for stupid repository elements in poms. 3) Let's fix the ?bug? in which a repository in a POM is used to look up artifacts other than the dependences of that very pom. 4) Let's fix the ?bug? in which a pluginRepository in a dependency effects lookups of plugins. pluginRepository elements should only have impact the starting POM or its parents. (I'm not 100% sure that this problem exists). All in all there's a tension. Repos move around and are managed, so putting them in POMs causes problems. Not putting them in POMs causes other problems. So I'm in favor of viewing repository elements in dependencies as hints rather than directions to add them unconditionally to the front of the search list. On Mon, Aug 1, 2011 at 3:58 PM, Paul Gier pg...@redhat.com wrote: Using a project local settings allows you to use the repo during build, but still have a clean pom in the repo when you release. We've experienced a lot of problems related to repos in the poms. On 08/01/2011 02:16 PM, Julien HENRY wrote: What is the point of putting a settings.xml in your SCM next to your pom.xml? In this case just add the repos in the root pom. ++ Julien - Mail original - De : Milos Kleint mkle...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Lundi 1 Août 2011 21h02 Objet : Re: [DISCUSS] Project local setting.xml hasn't that been the purpose of profiles.xml files back in 2.x before it was removed for 3.x? Milos On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier pg...@redhat.com wrote: I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Project local setting.xml
On 08/01/2011 03:09 PM, Benson Margulies wrote: I have several alternative design ideas. 0) If you religiously use a repository manager and mirrorOf *, you can prevent this rogues from bothering you. This only works when all the projects you work on use the same mirror settings. For me, this doesn't work, and I would like to have different mirror settings for different projects. 1) How about if the release / deploy process had an option to remove repositories from the POM? Yes, this would work well for me, but from what I understand, there are a lot of problems with modifying the POM right before deployment. It breaks gpg signing for example. 2) Let's design and implement basic repository redirection in maven itself, so that people don't have to set up an entire repo-man to compensate for stupid repository elements in poms. 3) Let's fix the ?bug? in which a repository in a POM is used to look up artifacts other than the dependences of that very pom. 4) Let's fix the ?bug? in which a pluginRepository in a dependency effects lookups of plugins. pluginRepository elements should only have impact the starting POM or its parents. (I'm not 100% sure that this problem exists). All in all there's a tension. Repos move around and are managed, so putting them in POMs causes problems. Not putting them in POMs causes other problems. So I'm in favor of viewing repository elements in dependencies as hints rather than directions to add them unconditionally to the front of the search list. I basically agree with you. IMO repositories in dependency POMs should just be ignored by default. This definitely seems like a bug to me, and I've heard a lot of complaints from others when their build starts downloading stuff from some seemingly random location on the internet. http://jira.codehaus.org/browse/MNG-3056 On Mon, Aug 1, 2011 at 3:58 PM, Paul Gier pg...@redhat.com wrote: Using a project local settings allows you to use the repo during build, but still have a clean pom in the repo when you release. We've experienced a lot of problems related to repos in the poms. On 08/01/2011 02:16 PM, Julien HENRY wrote: What is the point of putting a settings.xml in your SCM next to your pom.xml? In this case just add the repos in the root pom. ++ Julien - Mail original - De : Milos Kleint mkle...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Lundi 1 Août 2011 21h02 Objet : Re: [DISCUSS] Project local setting.xml hasn't that been the purpose of profiles.xml files back in 2.x before it was removed for 3.x? Milos On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier pg...@redhat.com wrote: I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [DISCUSS] Project local setting.xml
The issue to remove profiles.xml was MNG-4060[1] but it doesn't tell the reason.One of the comments contains a link to a thread I started when I discovered this removal.(man, that's already more than two years ago...)It should give some more background. -Robert http://jira.codehaus.org/browse/MNG-4060 Date: Mon, 1 Aug 2011 15:27:34 -0500 From: pg...@redhat.com To: dev@maven.apache.org Subject: Re: [DISCUSS] Project local setting.xml On 08/01/2011 03:09 PM, Benson Margulies wrote: I have several alternative design ideas. 0) If you religiously use a repository manager and mirrorOf *, you can prevent this rogues from bothering you. This only works when all the projects you work on use the same mirror settings. For me, this doesn't work, and I would like to have different mirror settings for different projects. 1) How about if the release / deploy process had an option to remove repositories from the POM? Yes, this would work well for me, but from what I understand, there are a lot of problems with modifying the POM right before deployment. It breaks gpg signing for example. 2) Let's design and implement basic repository redirection in maven itself, so that people don't have to set up an entire repo-man to compensate for stupid repository elements in poms. 3) Let's fix the ?bug? in which a repository in a POM is used to look up artifacts other than the dependences of that very pom. 4) Let's fix the ?bug? in which a pluginRepository in a dependency effects lookups of plugins. pluginRepository elements should only have impact the starting POM or its parents. (I'm not 100% sure that this problem exists). All in all there's a tension. Repos move around and are managed, so putting them in POMs causes problems. Not putting them in POMs causes other problems. So I'm in favor of viewing repository elements in dependencies as hints rather than directions to add them unconditionally to the front of the search list. I basically agree with you. IMO repositories in dependency POMs should just be ignored by default. This definitely seems like a bug to me, and I've heard a lot of complaints from others when their build starts downloading stuff from some seemingly random location on the internet. http://jira.codehaus.org/browse/MNG-3056 On Mon, Aug 1, 2011 at 3:58 PM, Paul Gier pg...@redhat.com wrote: Using a project local settings allows you to use the repo during build, but still have a clean pom in the repo when you release. We've experienced a lot of problems related to repos in the poms. On 08/01/2011 02:16 PM, Julien HENRY wrote: What is the point of putting a settings.xml in your SCM next to your pom.xml? In this case just add the repos in the root pom. ++ Julien - Mail original - De : Milos Kleint mkle...@gmail.com À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Lundi 1 Août 2011 21h02 Objet : Re: [DISCUSS] Project local setting.xml hasn't that been the purpose of profiles.xml files back in 2.x before it was removed for 3.x? Milos On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier pg...@redhat.com wrote: I'd like to discuss the possibility of Maven automatically looking for a project specific settings.xml file [1]. The main use case for this is to eliminate, or at least reduce, the need to add repositories to the poms. A setting.xml file could simply be added into scm into the root directory of the project. Then it would be checked out when the project is checked out. With multi-module projects, Maven would need to search up the directory tree to find the settings.xml file, but this could be made relatively simple by checking the parent dirs until Maven finds: (1) a settings.xml, (2) a directory with no pom.xml, or (3) the root directory The only problem I can think of in this case would be when small related projects can be checked out separately (similar to Maven plugins, or codehaus mojo). The project might not be able to find the settings.xml if it is not checked out with the project. Although I think this is a relatively minor issue. [1]http://jira.codehaus.org/browse/MNG-4686 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail:
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Hi I've done some testing, and as far as site generation all is well. Unfortunately site:stage-deploy deploys the site to the wrong place. This is the same issue I saw when releasing, and staging the site for, Maven Site Plugin 2.3. Here's what I get when doing 'mvn clean site:site site:deploy' on maven-checkstyle-plugin using maven-site-plugin:3.0. maven-site-plugin:2.3 does the same thing, but 3.0-beta-3 works correctly. So this is a regression compared to 3.0-beta-3. [INFO] --- maven-site-plugin:3.0:stage-deploy (default-cli) @ maven-checkstyle-plugin --- [INFO] Using this server ID for stage deploy: apache.website [INFO] Using this base URL for stage deploy: scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT [INFO] Parent project loaded from repository: org.apache.maven.plugins:maven-plugins:pom:21 [INFO] Parent project loaded from repository: org.apache.maven:maven-parent:pom:20 [INFO] Parent project loaded from repository: org.apache:apache:pom:9 : Keyboard interactive required, supplied password is ignored Password: : scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Opened [INFO] Pushing G:\apache\maven\trunks\plugins\maven-checkstyle-plugin\target\site [INFO] to scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: mkdir -p /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: mkdir -p /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: scp -t /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/wagon592489540427231356.zip Uploading: plugins/maven-checkstyle-plugin/wagon592489540427231356.zip to scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ ### Transfer finished. 224640 bytes copied in 1.699 seconds Executing command: cd /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin; unzip -q -o wagon592489540427231356.zip; rm -f wagon592489540427231356.zip Executing command: chmod -Rf g+w,a+rX /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Disconnecting scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Disconnected Notice how it gets deployed to /plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/ instead of /plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ Lukas, can this have anything to do with your refactoring of the staging functionality? How should we handle this? I propose we go ahead with the release, but add this as a known issue in the announcement. And then we get started on a fix right away. This release is way to big as it is. On 2011-07-30 17:03, Dennis Lundberg wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins is sending more e-mails now
Greetings, 2011/8/1 Arnaud Héritier aherit...@gmail.com: FYI, the Jenkins team was working recently into merging a part of the Editable Email feature into the default one. This is mostly captured and available via [1] and [2]. While not strictly related, [3] is quite interesting for people curious in this realm. [1] https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda [2] https://wiki.jenkins-ci.org/display/JENKINS/The+new+EMailer [3] https://wiki.jenkins-ci.org/display/JENKINS/Convert+standard+mail+notifications+to+use+the+Mail-Ext+Publisher+plugin -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Release plugin version 2.2.1
A bit late, it might arrive after the mail of the release, but anyway: +1 for me too, just tested it on our main multimodule project. Thanks for the work, Stephen. 2011/7/29 Lukas Theussl ltheu...@apache.org +1 -Lukas On 07/28/2011 04:56 PM, Stephen Connolly wrote: Hi, This is a patch release to fix a particularly nasty regression: http://jira.codehaus.org/**browse/MRELEASE-697http://jira.codehaus.org/browse/MRELEASE-697 We solved 3 issues: http://jira.codehaus.org/**secure/ReleaseNote.jspa?** projectId=11144styleName=**Htmlversion=17502http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=17502 Staging repo: https://repository.apache.org/**content/repositories/maven-**009/https://repository.apache.org/content/repositories/maven-009/ Source distribution: https://repository.apache.org/**content/repositories/maven-** 009/org/apache/maven/release/**maven-release/2.2.1/maven-** release-2.2.1-source-release.**ziphttps://repository.apache.org/content/repositories/maven-009/org/apache/maven/release/maven-release/2.2.1/maven-release-2.2.1-source-release.zip SCM tag: http://svn.apache.org/repos/**asf/maven/release/tags/maven-** release-2.2.1http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2.1 Staging site: http://maven.apache.org/**plugins/maven-release-plugin-**2.2.1/http://maven.apache.org/plugins/maven-release-plugin-2.2.1/ http://maven.apache.org/maven-**release/staging/http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/**guides/development/guide-** testing-releases.htmlhttp://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/**project-site.htmlhttp://www.apache.org/dev/project-site.html(and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Dennis Lundberg wrote: Hi I've done some testing, and as far as site generation all is well. Unfortunately site:stage-deploy deploys the site to the wrong place. This is the same issue I saw when releasing, and staging the site for, Maven Site Plugin 2.3. Here's what I get when doing 'mvn clean site:site site:deploy' on maven-checkstyle-plugin using maven-site-plugin:3.0. maven-site-plugin:2.3 does the same thing, but 3.0-beta-3 works correctly. So this is a regression compared to 3.0-beta-3. [INFO] --- maven-site-plugin:3.0:stage-deploy (default-cli) @ maven-checkstyle-plugin --- [INFO] Using this server ID for stage deploy: apache.website [INFO] Using this base URL for stage deploy: scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT [INFO] Parent project loaded from repository: org.apache.maven.plugins:maven-plugins:pom:21 [INFO] Parent project loaded from repository: org.apache.maven:maven-parent:pom:20 [INFO] Parent project loaded from repository: org.apache:apache:pom:9 : Keyboard interactive required, supplied password is ignored Password: : scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Opened [INFO] Pushing G:\apache\maven\trunks\plugins\maven-checkstyle-plugin\target\site [INFO] to scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: mkdir -p /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: mkdir -p /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin Executing command: scp -t /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/wagon592489540427231356.zip Uploading: plugins/maven-checkstyle-plugin/wagon592489540427231356.zip to scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ ### Transfer finished. 224640 bytes copied in 1.699 seconds Executing command: cd /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin; unzip -q -o wagon592489540427231356.zip; rm -f wagon592489540427231356.zip Executing command: chmod -Rf g+w,a+rX /www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Disconnecting scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ - Session: Disconnected Notice how it gets deployed to /plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/ instead of /plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/ Lukas, can this have anything to do with your refactoring of the staging functionality? Yes, most probably. After MSITE-537, if you stage-deploy from a sub-module, the relative path from the top-level site is added to the stage-deploy url. This doesn't seem to work if the default stagingSiteURL is overridden somewhere on the way, probably related to MSITE-600. Unfortunately, I don't have time right now to look at it, but promise I will ASAP when I'm back. -Lukas How should we handle this? I propose we go ahead with the release, but add this as a known issue in the announcement. And then we get started on a fix right away. This release is way to big as it is. On 2011-07-30 17:03, Dennis Lundberg wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ 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
