[jira] Updated: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=all ] Danie Roux updated MIDEA-39: Attachment: module-dependencies.patch > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Type: Improvement > Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 > Reporter: Vikash Ramanlal > Assignee: Brett Porter > Priority: Minor > Attachments: module-dependencies.patch > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2234) activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty
activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty Key: MNG-2234 URL: http://jira.codehaus.org/browse/MNG-2234 Project: Maven 2 Type: Bug Versions: 2.0.4 Reporter: Manfred Geiler When i have this settings.xml file in my user home dir, the activeProfile setting is simply ignored by Maven: env-test Adding an empty profiles section does not help: env-test Well, adding a dummy profile makes it work: dummy env-test Funny, isn't it? Regards, Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-852) Mysql Java connector 3.1.12
[ http://jira.codehaus.org/browse/MAVENUPLOAD-852?page=comments#action_63883 ] Carlos Sanchez commented on MAVENUPLOAD-852: Still wrong, use this scm:svn:http://svn.mysql.com/svnpublic/connector-j/trunk/connector-j scm:svn:http://svn.mysql.com/svnpublic/connector-j/trunk/connector-j http://svn.mysql.com/svnpublic/connector-j/trunk/connector-j and http://dev.mysql.com/usingmysql/java/ > Mysql Java connector 3.1.12 > --- > > Key: MAVENUPLOAD-852 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-852 > Project: maven-upload-requests > Type: Task > Reporter: Oliver Nautsch > > > Mysql Java connector 3.1.12 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-97) make release:perform upload progress overwrite the previous xxK/yyK uploaded line
make release:perform upload progress overwrite the previous xxK/yyK uploaded line - Key: MRELEASE-97 URL: http://jira.codehaus.org/browse/MRELEASE-97 Project: Maven 2.x Release Plugin Type: Improvement Versions: 2.0-beta-4 Environment: maven 2.0.4, head versions of all plugins, win xp, sun jdk 1.5.0_06 Reporter: Marcel Schutte Attachments: ReleaseTestWEB.zip, maven-release-plugin.diff, plexus-utils.diff The current CommandLineUtils.executeCommandLine() in plexus-utils uses the StreamPumper class to copy the output of the 'mvn deploy' call. Because this class is line based, it cannot distinguish between a standard newline and a '\r'. Because of this the upload progress doesn't overwrite itself as the download progress usually does, but writes each step on a new line (see MRELEASE-55). I've created 2 patches, one for the release-plugin itself and one for plexus-utils. I'm submitting the plexus-utils patch here as well, because of the direct relation with this report. To test, replace the plexus-utils-1.1.jar in /core with the newly built plexus-utils-1.2-SNAPSHOT.jar. After this, import the web project in ReleaseTestWEB.zip into CVS and update the scm url in the pom. Perform a release:prepare and release:perform and verify that the upload counter stays on the same line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-42) wagon-scm (svn provider) - large paths under windows breaks download.
wagon-scm (svn provider) - large paths under windows breaks download. - Key: WAGON-42 URL: http://jira.codehaus.org/browse/WAGON-42 Project: wagon Type: Bug Versions: 1.0-alpha-6 Reporter: Joakim Erdfelt I have a deep path in windows, plus a repository housed in svn. When performing a 'mvn compile', it fails with not finding the artifact. Using mvn --debug shows no error message from wagon-scm (svn). If I go into the target/checkout/ directory, i see an empty directory with the '.svn' working directory. performing a 'svn update .' in that directory reveals the reason ... [EMAIL PROTECTED] /c/code/mergere/amex/AXP-EntBuildEnv/tools/branches/mergere-discovery-wizard/mergere-discovery-core/target/checkout/org/apache/maven/repository/maven-repository-indexer/1.0-SNAPSHOT $ svn update . svn: Can't open file '.svn/text-base/maven-repository-indexer-1.0-20060418.201022-1.jar.md5.svn-base': File name too long I think a general "if windows, and path exceeds maximum, throw error before attempting process' kind of functionality needs to exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-852) Mysql Java connector 3.1.12
[ http://jira.codehaus.org/browse/MAVENUPLOAD-852?page=comments#action_63888 ] Oliver Nautsch commented on MAVENUPLOAD-852: Sorry. I didn't read the pom documentation so carefully as necessary. Originally my pom was a copy of the 3.1.11 version. I thought this will be good enough. But I hope everthing is correct now. The bundle is updated. > Mysql Java connector 3.1.12 > --- > > Key: MAVENUPLOAD-852 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-852 > Project: maven-upload-requests > Type: Task > Reporter: Oliver Nautsch > > > Mysql Java connector 3.1.12 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2234) activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty
[ http://jira.codehaus.org/browse/MNG-2234?page=comments#action_63891 ] John Casey commented on MNG-2234: - Assuming the activeProfiles section is only there to activate profiles that you've provided, how would you expect this to act? > activeProfile in ~/.m2/settings.xml is ignored when profiles section is > missing or empty > > > Key: MNG-2234 > URL: http://jira.codehaus.org/browse/MNG-2234 > Project: Maven 2 > Type: Bug > Versions: 2.0.4 > Reporter: Manfred Geiler > > > When i have this settings.xml file in my user home dir, the activeProfile > setting is simply ignored by Maven: > > > env-test > > > Adding an empty profiles section does not help: > > > > > env-test > > > Well, adding a dummy profile makes it work: > > > > dummy > > > > env-test > > > Funny, isn't it? > Regards, > Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2234) activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty
[ http://jira.codehaus.org/browse/MNG-2234?page=comments#action_63894 ] Manfred Geiler commented on MNG-2234: - The actual profiles are defined in the pom.xml files (= best practice for environment settings - see http://maven.apache.org/guides/introduction/introduction-to-profiles.html). To activate one of these profiles without always having to add a -P foobar option on the command line, it makes perfect sense to have this profile activation in the user's settings.xml. And it really works. But only when there is a dummy profile in the settings.xml file. > activeProfile in ~/.m2/settings.xml is ignored when profiles section is > missing or empty > > > Key: MNG-2234 > URL: http://jira.codehaus.org/browse/MNG-2234 > Project: Maven 2 > Type: Bug > Versions: 2.0.4 > Reporter: Manfred Geiler > > > When i have this settings.xml file in my user home dir, the activeProfile > setting is simply ignored by Maven: > > > env-test > > > Adding an empty profiles section does not help: > > > > > env-test > > > Well, adding a dummy profile makes it work: > > > > dummy > > > > env-test > > > Funny, isn't it? > Regards, > Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-844) Easymock class extension 2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-844?page=all ] Henri Tremblay reopened MAVENUPLOAD-844: I just learn the hard way how maven 2 is working compared to maven 1... So indeed, the cglib dependency is wrong in the pom. I've just fix it, tested it and re-upload the bundle at the same place. Can you please upload the new version? Sorry about that, Henri > Easymock class extension 2.2 > > > Key: MAVENUPLOAD-844 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-844 > Project: maven-upload-requests > Type: Task > Reporter: Henri Tremblay > Assignee: Carlos Sanchez > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-844) Easymock class extension 2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-844?page=all ] Carlos Sanchez closed MAVENUPLOAD-844: -- Resolution: Fixed > Easymock class extension 2.2 > > > Key: MAVENUPLOAD-844 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-844 > Project: maven-upload-requests > Type: Task > Reporter: Henri Tremblay > Assignee: Carlos Sanchez > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-662) "Show Projects" page shows a "Build Error" icon, but clicking on the "Build" number link, the State is "Build Success".
"Show Projects" page shows a "Build Error" icon, but clicking on the "Build" number link, the State is "Build Success". --- Key: CONTINUUM-662 URL: http://jira.codehaus.org/browse/CONTINUUM-662 Project: Continuum Type: Bug Reporter: Edwin Punzalan This happened with the MPIR project. But clicking the "Build Now" icon updated both icons to show "Build Success". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-662) "Show Projects" page shows a "Build Error" icon, but clicking on the "Build" number link, the State is "Build Success".
[ http://jira.codehaus.org/browse/CONTINUUM-662?page=comments#action_63902 ] Edwin Punzalan commented on CONTINUUM-662: -- Brett mentioned something about a stage before the build starts, wherein when continuum gets an error, and its not reported. > "Show Projects" page shows a "Build Error" icon, but clicking on the "Build" > number link, the State is "Build Success". > --- > > Key: CONTINUUM-662 > URL: http://jira.codehaus.org/browse/CONTINUUM-662 > Project: Continuum > Type: Bug > Reporter: Edwin Punzalan > > > This happened with the MPIR project. > But clicking the "Build Now" icon updated both icons to show "Build Success". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-118) Provide a schema for site.xml
Provide a schema for site.xml - Key: MSITE-118 URL: http://jira.codehaus.org/browse/MSITE-118 Project: Maven 2.x Site Plugin Type: Wish Versions: 2.0 Reporter: Wendy Smoak Priority: Minor Fix For: 2.0 Brett mentioned that a schema for site.xml will be available with maven-site-plugin 2.0 final. Just logging a reminder issue as I don't see it in svn or at http://maven.apache.org/xsd/ . http://mail-archives.apache.org/mod_mbox/maven-users/200602.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MRAR-6) Create tests for Rar plugin using test harness plugin
[ http://jira.codehaus.org/browse/MRAR-6?page=all ] Allan Ramirez reopened MRAR-6: -- the test fails when it is built in unix environment... > Create tests for Rar plugin using test harness plugin > - > > Key: MRAR-6 > URL: http://jira.codehaus.org/browse/MRAR-6 > Project: Maven 2.x Rar Plugin > Type: Test > Reporter: Allan Ramirez > Assignee: Allan Ramirez > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRAR-6) Create tests for Rar plugin using test harness plugin
[ http://jira.codehaus.org/browse/MRAR-6?page=all ] Allan Ramirez closed MRAR-6: Resolution: Fixed Fixed in svn > Create tests for Rar plugin using test harness plugin > - > > Key: MRAR-6 > URL: http://jira.codehaus.org/browse/MRAR-6 > Project: Maven 2.x Rar Plugin > Type: Test > Reporter: Allan Ramirez > Assignee: Allan Ramirez > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MIDEA-43) Utilize plugin testing harness and create test cases for the Idea plugin
[ http://jira.codehaus.org/browse/MIDEA-43?page=all ] Edwin Punzalan updated MIDEA-43: Fix Version: 2.0 > Utilize plugin testing harness and create test cases for the Idea plugin > > > Key: MIDEA-43 > URL: http://jira.codehaus.org/browse/MIDEA-43 > Project: Maven 2.x Idea Plugin > Type: Task > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Fix For: 2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2235) unify .m2 configuration and have a "super settings"
unify .m2 configuration and have a "super settings" --- Key: MNG-2235 URL: http://jira.codehaus.org/browse/MNG-2235 Project: Maven 2 Type: Bug Reporter: Brett Porter the ".m2/settings.xml" configuration is located in several places, and instead should be a configuration solely of the default maven settings builder to make it easily changable. Also, any defaults in the settings model should come from a super model implemented in a similar fashion to the super pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2235) unify .m2 configuration and have a "super settings"
[ http://jira.codehaus.org/browse/MNG-2235?page=all ] Brett Porter updated MNG-2235: -- Fix Version: 2.1 > ./bootstrap/bootstrap-mini/src/main/java/org/apache/maven/bootstrap/Bootstrap.java > ./bootstrap/bootstrap-mini/src/main/java/org/apache/maven/bootstrap/settings/Settings.java unnecessary to change > ./maven-embedder/src/main/java/org/apache/maven/embedder/MavenEmbedder.java > ./maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/AbstractArtifactTask.java ok, these should be changed to rely on the defaults from the settings builder / to use the settings builder > ./maven-core/src/main/java/org/apache/maven/cli/MavenCli.java This is just in the CLI text - I'd suggest we remove that reference as it's not always correct. > ./maven-core/src/main/java/org/apache/maven/plugin/PluginConfigurationException.java Just in exception text - I'd suggest removing the .m2 reference as it may be elsewhere. > ./maven-core-it-verifier/src/main/java/org/apache/maven/it/Verifier.java Only for integration tests, and I think we can find an alternate way to abstract this. > ./maven-settings/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java This is the one that needs to be changed. If we can push that into a components definition we can override it in the main application. > ./maven-artifact-test/src/main/java/org/apache/maven/artifact/test/ArtifactTestCase.java Should be changed to rely on the default from the settings builder. > unify .m2 configuration and have a "super settings" > --- > > Key: MNG-2235 > URL: http://jira.codehaus.org/browse/MNG-2235 > Project: Maven 2 > Type: Bug > Reporter: Brett Porter > Fix For: 2.1 > > > the ".m2/settings.xml" configuration is located in several places, and > instead should be a configuration solely of the default maven settings > builder to make it easily changable. > Also, any defaults in the settings model should come from a super model > implemented in a similar fashion to the super pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGELOG-34) Add tests to changelog-plugin and utilize the testing-harness
[ http://jira.codehaus.org/browse/MCHANGELOG-34?page=all ] Edwin Punzalan updated MCHANGELOG-34: - Fix Version: 2.0 > Add tests to changelog-plugin and utilize the testing-harness > - > > Key: MCHANGELOG-34 > URL: http://jira.codehaus.org/browse/MCHANGELOG-34 > Project: Maven 2.x Changelog Plugin > Type: Test > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Fix For: 2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPIR-43) Use the plugin testing harness and add tests for the project-info-report mojos
[ http://jira.codehaus.org/browse/MPIR-43?page=all ] Edwin Punzalan updated MPIR-43: --- Fix Version: 2.0 > Use the plugin testing harness and add tests for the project-info-report mojos > -- > > Key: MPIR-43 > URL: http://jira.codehaus.org/browse/MPIR-43 > Project: Maven 2.x Project Info Reports Plugin > Type: Test > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Fix For: 2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=comments#action_63906 ] Brett Porter commented on MRELEASE-6: - so, the fix here needs to be that we check in every module individually, unless its a subdirectory of some other module? > Multiproject Release: No check in > - > > Key: MRELEASE-6 > URL: http://jira.codehaus.org/browse/MRELEASE-6 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: Windows XP, Eclipse Workspace > Reporter: Bernd Mau > Priority: Critical > > > I tried to release a multiproject with 5 modules (on a Branch). Well, > the POMs of all modules are changed and there are some dependencies > which have been updated correctly. But only the master has been checked > in correctly. > I'm changed the recommended layout, to fit in an eclipse workspace. I > have one master at the same level as the other modules. > The module section of the master pom.xml: > > ../hhla.library.pom > ../hhla.library.site > ../hhla.lang > ../hhla.common.log4jx > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-94) Modified Parent POM is not commited
[ http://jira.codehaus.org/browse/MRELEASE-94?page=all ] Brett Porter closed MRELEASE-94: Assign To: Brett Porter Resolution: Duplicate dupe of MRELEASE-41, but don't believe it is the same as MRELEASE-6 > Modified Parent POM is not commited > --- > > Key: MRELEASE-94 > URL: http://jira.codehaus.org/browse/MRELEASE-94 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-3 > Environment: Windows 2k, or Windows XP. JDK 1.4.2, scpexe=pscp sshexe=plink > cvs=cvs.exe CVS_RSH=plink. Key authentication via pageant > Reporter: Todd Nine > Assignee: Brett Porter > Priority: Blocker > > > I can successfully tag all sub projects of a parent pom (with the standard > directory structure), but I'm unable complete the release:prepare operation > since the parent POM is not checked in. As a result I am unable to perform a > multi-project release. Each child pom has the scm repotisotries declared in > the pom. Attached is verbose output of the command. > mvn -Duser.name=c200506 -X clean release:prepare > [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: > null:maven-plugin-parameter-documenter:jar:2.0 from the repository. > [DEBUG] > org.apache.maven:maven-plugin-parameter-documenter:jar:2.0:runtime (selected > for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - > nearer found: 1.1) > [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: > null:maven-error-diagnostics:jar:2.0 from the repository. > [DEBUG] org.apache.maven:maven-error-diagnostics:jar:2.0:runtime > (selected for runtime)[DEBUG] Retrieving parent-POM: > org.apache.maven:maven::2.0 for project: org.apac > he.maven:maven-monitor:jar:2.0 from the repository. > [DEBUG] org.apache.maven:maven-monitor:jar:2.0:runtime (selected for > runtime > ) > [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: > null:mav > en-settings:jar:2.0 from the repository. > [DEBUG] org.apache.maven:maven-settings:jar:2.0:runtime (selected for > runtim > e) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - > near > er found: 1.1) > [DEBUG] > org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5:runtim > e (selected for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - > near > er found: 1.1) > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5:runtime > (selected > for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - > near > er found: 1.1) > [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: > org.apac > he.maven:maven-plugin-descriptor:jar:2.0 from the repository. > [DEBUG] org.apache.maven:maven-plugin-descriptor:jar:2.0:runtime > (selected f > or runtime) > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for > ru > ntime) > [DEBUG] commons-cli:commons-cli:jar:1.0:runtime (selected for runtime) > [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5:runtime > (selected f > or runtime) > [DEBUG] com.jcraft:jsch:jar:0.1.23:runtime (selected for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - > near > er found: 1.1) > [DEBUG] Retrieving parent-POM: > org.apache.maven.reporting:maven-reporting::2.0 f > or project: null:maven-reporting-api:jar:2.0 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: > org.apac > he.maven.reporting:maven-reporting:pom:2.0 from the repository. > [DEBUG] org.apache.maven.reporting:maven-reporting-api:jar:2.0:runtime > (sele > cted for runtime) > [DEBUG] doxia:doxia-sink-api:jar:1.0-alpha-4:runtime (selected for > runtime > ) > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for > runt > ime) > [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: > org.apac > he.maven:maven-plugin-registry:jar:2.0 from the repository. > [DEBUG] org.apache.maven:maven-plugin-registry:jar:2.0:runtime (selected > for > runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - > near > er found: 1.1) > [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for > runtim > e) > [DEBUG] org.apache.maven:maven-artifact:jar:2.0:runtime (selected for > runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - > nearer > found: 1.1) > [DEBUG] Skipping disabled repository central > [DEBUG] maven-scm-manager-plexus: resolved to version > 1.0-beta-3-20060330.123807 > -1 from repository apache.snapshots > [DEBUG] Retrieving parent-POM: > org.apache.maven.scm:maven-scm-managers::1.0-beta > -3-SNAPSHOT for project: > null:maven-scm-manager-plexus:jar:1.0-beta-3-20060330.1 > 23807-1 from
[jira] Commented: (MRELEASE-58) Update the release.properties if pom.xml have been updated (SCM
[ http://jira.codehaus.org/browse/MRELEASE-58?page=comments#action_63907 ] Brett Porter commented on MRELEASE-58: -- I don't think release.properties should be caching this info at all if it is always to be read from the pom > Update the release.properties if pom.xml have been updated (SCM > > > Key: MRELEASE-58 > URL: http://jira.codehaus.org/browse/MRELEASE-58 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Eric Hartmann > > > I experienced the same troubles as described in > http://www.nabble.com/-M2-What-is-wrong-with-my-scm-url--t480810.html#a1308659 > . > The build error print : > Embedded error: Can't load the scm provider. > No such provider: 'rver'. > And with mvn -X give me : > [DEBUG] Artifact resolved > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-4-SNAPSHOT:prepare' > --> > [DEBUG] (f) basedir = /projects/jing-trang > [DEBUG] (f) generateReleasePoms = false > [DEBUG] (f) interactive = true > [DEBUG] (f) localRepository = [local] -> > file:///home/ehartmann/.m2/repository > [DEBUG] (f) reactorProjects = [EMAIL PROTECTED] > [DEBUG] (f) resume = true > [DEBUG] (f) settings = [EMAIL PROTECTED] > [DEBUG] (f) tagBase = ../tags > [DEBUG] (f) urlScm = cvs:pserver:cvs.sharedvalue.com:/opt/cvs/:jing-trang > [DEBUG] -- end configuration -- > Unfortunately I was not aware of the url is taken in release.properties > (since the urlScm is right in the debug log) and look for this issue for a > couple of hours before finding the explanation in the mailing list. > It may be usefull to recreate release.properties if pom.xml have been updated > since it's creation and/or log the information taken in release.properties to > give a hint to developers (who have not carefully read > http://maven.apache.org/scm as myself :-)) that made an error in the scm url. > I create a new bug report instead of http://jira.codehaus.org/browse/MNG-1105 > as I think it's not quite the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-40) svn authentication fails during release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-40?page=all ] Brett Porter closed MRELEASE-40: Assign To: Brett Porter Resolution: Duplicate > svn authentication fails during release:prepare > --- > > Key: MRELEASE-40 > URL: http://jira.codehaus.org/browse/MRELEASE-40 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Jorg Heymans > Assignee: Brett Porter > > > I have a problem getting maven to authenticate against the SVN repository. > The pom i try to execute is here : > http://svn.apache.org/repos/asf/cocoon/whiteboard/maven2/cocoon-flat-layout/pom.xml > > command output : > [INFO] [release:prepare] > [INFO] What tag name should be used? > 2.2.0 > [INFO] Verifying there are no local modifications ... > [INFO] Checking lineage for snapshots ... > [INFO] Checking dependencies for snapshots ... > [INFO] Checking plugins for snapshots ... > [INFO] What is the release version for 'apache-cocoon:cocoon'? [2.2] > 2.2.1 > [INFO] Checking in modified POMs > Provider message: > The svn command failed. > Command output: > svn: Commit failed (details follow): > svn: CHECKOUT of > '/repos/asf/!svn/ver/330830/cocoon/whiteboard/maven2/cocoon-flat-layout/p > om.xml': authorization failed (https://svn.apache.org) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error is occurred in the checkin process. > Embedded error: Error! > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 27 seconds > [INFO] Finished at: Fri Nov 04 17:03:32 CET 2005 > [INFO] Final Memory: 3M/6M > [INFO] > > I have write access to the repository, I can commit using commandline svn > without having to give username or password. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-67) Need to look up user name in settings.xml if not specify in command line or url
[ http://jira.codehaus.org/browse/MRELEASE-67?page=comments#action_63909 ]
Brett Porter commented on MRELEASE-67:
--
this is not a bug, but a missing feature. The SCM settings do not consult the
settings.xml at all (not , though that would be good in the future if
they didn't rely on id, and properties are not system properties)
> Need to look up user name in settings.xml if not specify in command line or
> url
>
>
> Key: MRELEASE-67
> URL: http://jira.codehaus.org/browse/MRELEASE-67
> Project: Maven 2.x Release Plugin
> Type: Bug
> Reporter: Dan Tran
>
>
> Here are discussion on the list.
> Yes, i think it's a bug. We must set username to ${user.name} if other places
> don't set it.
> Emmanuel
> dan tran a écrit :
> - Hide quoted text -
> > any one?
> >
> > -D
> >
> >
> > On 1/5/06, dan tran <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>There are 3 places to look for in this order
> >>
> >> Command line
> >> settings.xml
> >> connectionUrl
> >>
> >>However in maven-release-plugin, if user does not provide username
> >>via command line (ie -Dusername=xyz),
> >>username is default to system property ${user.name} and by passing
> >>settings.xml.
> >>
> >>is it a bug?
> >>
> >>
> >>-Dan
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-84) Check in release.properties into CVS during the tag then remove
[ http://jira.codehaus.org/browse/MRELEASE-84?page=all ] Brett Porter closed MRELEASE-84: Assign To: Brett Porter Resolution: Won't Fix > Check in release.properties into CVS during the tag then remove > --- > > Key: MRELEASE-84 > URL: http://jira.codehaus.org/browse/MRELEASE-84 > Project: Maven 2.x Release Plugin > Type: Improvement > Environment: windows 2000 > Reporter: Todd Nine > Assignee: Brett Porter > > > Is it possible to add an enhancement that will check in the > release.properties before tagging takes place? Alternatively it could be > added and tagged after the tagging of the initial project to ensure the tag > went smoothly This way any developer can pull down the source with a give > tag, say foo-1_0_5, and perform a mvn release:perform to quickly create a > build. A good use would be if the local maven 2 repository is lost due to > system failure, the artifacts could easily be re-created from the SCM tag. > Todd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-88) Rewritten pom's loose comments and XSD definition
[ http://jira.codehaus.org/browse/MRELEASE-88?page=all ] Brett Porter closed MRELEASE-88: Assign To: Brett Porter Resolution: Duplicate > Rewritten pom's loose comments and XSD definition > - > > Key: MRELEASE-88 > URL: http://jira.codehaus.org/browse/MRELEASE-88 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-3 > Reporter: Geoffrey De Smet > Assignee: Brett Porter > > > For example it updates all modules's 0.1.0-SNAPSHOT to 0.1.0 prior to release > and 0.2.0-SNAPSHOT afterwards, but at a cost: > 1) pom comments are removed > TODO's and documented hacks are removed. > 2) schema definition is removed > No more IDE helping us write our pom's. > 3) the pom is reformatted > This is acceptable but still slightly annoying -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-96) Improve handling of Super POM snapshots.
[ http://jira.codehaus.org/browse/MRELEASE-96?page=all ] Brett Porter closed MRELEASE-96: Assign To: Brett Porter Resolution: Won't Fix if you are using coordinated versioning, then the parent is always released with the child, and this isn't a problem. If you aren't, you should leave the parent version as the released version until you need the snapshot. If you need the snapshot, the release plugin is right to complain if you are using it and the parent has been released. Hope that makes sense... we still aim to improve this without the need of the tools in Maven 2.1. > Improve handling of Super POM snapshots. > > > Key: MRELEASE-96 > URL: http://jira.codehaus.org/browse/MRELEASE-96 > Project: Maven 2.x Release Plugin > Type: Improvement > Versions: 2.0-beta-3 > Reporter: Joerg Schaible > Assignee: Brett Porter > > > The main reason for a super POM is to harmonize the version of the > dependencies with a dependencyManagement section in the super pom. Therefore > all other poms will reference the super pom as parent. To ensure consistency > between a lot of POMs the super pom is/must always refered as snapshot > version. This requierement collides with the release management. The release > plugin always complains about the snapshot version of the parent. > The plugin should support the scenario by comparing the last released version > of the parent POM and replace the snapshot version on its own, if the > snapshot version of the parent has not changed compared to the last release > of the parent (i.e. only the version is different in the parent POM). > release:perform should then restore the snapshot version of the parent again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-73) Add some kind of exclusion filters on subdirectories which are not submodules
[ http://jira.codehaus.org/browse/MRELEASE-73?page=comments#action_63911 ]
Brett Porter commented on MRELEASE-73:
--
this is incredibly hard to identify. For example - is "src" included? It should
be, but its not in the module list. How do you identify what is and isn't?
How about a configuration item "scmExcludes" instead so you get the control?
> Add some kind of exclusion filters on subdirectories which are not submodules
> -
>
> Key: MRELEASE-73
> URL: http://jira.codehaus.org/browse/MRELEASE-73
> Project: Maven 2.x Release Plugin
> Type: Improvement
> Reporter: Grzegorz Slowikowski
> Priority: Trivial
>
>
> I will describe this using an example.
> Now, when releasing Maven, all subdirectories including maven-artifact-ant
> and maven-embedder are copied to tag.
> Maven-artifact-ant and maven-embedder are not included in maven as modules
> and are released separately.
> So they are copied to tags twice:
> - to tag maven-{version} while releasing maven
> - to their own tags (maven-artifact-ant-{version} and
> maven-embedder-{version}) while releasing them
> Their presence in maven-{version} tag does not make sense. They could be
> excluded in Maven pom.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MDEPLOY-28) Deployment should delete remote files and create new ones instead of modifying them
[ http://jira.codehaus.org/browse/MDEPLOY-28?page=all ] Carlos Sanchez updated MDEPLOY-28: -- Priority: Critical (was: Major) > Deployment should delete remote files and create new ones instead of > modifying them > --- > > Key: MDEPLOY-28 > URL: http://jira.codehaus.org/browse/MDEPLOY-28 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.3 > Reporter: Carlos Sanchez > Priority: Critical > Fix For: 2.3 > > > Remote files usually are non group writable while the directory is to prevent > changes in the files without knowing who changed it (eg. apache repository > policy) > So deployment should delete metadata files and create new ones instead of > editing them -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-64) are stripped on release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-64?page=all ]
Brett Porter updated MRELEASE-64:
-
Fix Version: 2.0-beta-4
> are stripped on release:prepare
> ---
>
> Key: MRELEASE-64
> URL: http://jira.codehaus.org/browse/MRELEASE-64
> Project: Maven 2.x Release Plugin
> Type: Bug
> Reporter: Vincent Massol
> Assignee: Jason van Zyl
> Priority: Blocker
> Fix For: 2.0-beta-4
>
>
> {noformat}
> Author: vmassol
> Date: Mon Dec 26 00:42:18 2005
> New Revision: 359040
> URL: http://svn.apache.org/viewcvs?rev=359040&view=rev
> Log:
> [maven-release-plugin] prepare release maven-clover-plugin-2.0
> Modified:
> maven/plugins/trunk/maven-clover-plugin/pom.xml
> Modified: maven/plugins/trunk/maven-clover-plugin/pom.xml
> URL:
> http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-clover-plugin/pom.xml?rev=359040&r1=359039&r2=359040&view=diff
> ==
> --- maven/plugins/trunk/maven-clover-plugin/pom.xml (original)
> +++ maven/plugins/trunk/maven-clover-plugin/pom.xml Mon Dec 26 00:42:18
> +++ 2005
> @@ -1,23 +1,20 @@
> -
> +
>
> maven-plugin-parent
> org.apache.maven.plugins
> 2.0.1
>
> -
> -2.0.1
> -
>4.0.0
>maven-clover-plugin
>maven-plugin
>Maven Clover Plugin
> - 2.0-SNAPSHOT
> + 2.0
>Maven plugin for Clover
> - 2005
>
> jira
> http://jira.codehaus.org/browse/MCLOVER
>
> + 2005
>
>
>vmassol
> @@ -62,24 +59,4 @@
>2.0
>
>
> -
> -
> +
> \ No newline at end of file
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-57) ../tags doesn't work
[ http://jira.codehaus.org/browse/MRELEASE-57?page=all ]
Brett Porter updated MRELEASE-57:
-
Fix Version: 2.0-beta-4
> ../tags doesn't work
>
>
> Key: MRELEASE-57
> URL: http://jira.codehaus.org/browse/MRELEASE-57
> Project: Maven 2.x Release Plugin
> Type: Bug
> Reporter: Brett Porter
> Fix For: 2.0-beta-4
>
>
> the default tag base of ../tags doesn't work, even if ../tags is checked out
> which is infrequent. This should instead be ${urlScm}/../tags instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MPCLOVER-47) Clover report is not generated when using Maven AspectJ plugin
[ http://jira.codehaus.org/browse/MPCLOVER-47?page=comments#action_63912 ] Lukas Theussl commented on MPCLOVER-47: --- Ok, I think I got it now. ;) If you don't need the aspects during site generation then you can just comment out the preGoal, you should get the clover report as normal then, I just need to figure out why this preGoal definition disturbs the clover plugin... > Clover report is not generated when using Maven AspectJ plugin > -- > > Key: MPCLOVER-47 > URL: http://jira.codehaus.org/browse/MPCLOVER-47 > Project: maven-clover-plugin > Type: Bug > Versions: 1.10 > Environment: Maven 1.0.2 on Windows XP > Reporter: Glauber Vinícius Ferreira > Priority: Blocker > Attachments: Introduction Example.zip, aspectjtest.zip > > > When I am using AspectJ plugin with this lines in my maven.xml file: > > > > the Clover report is not generated. The following message is presented: > clover:report: > [echo] No Clover database found, skipping report generation > The folder "target\clover\database" stays empty. > -- > When I am using AspectJ plugin with this lines in my maven.xml file: > > > > an empty Clover report is generated, although there is one test in the > project. The following message is presented: > [clover-report] No coverage data found for 'C:\eclipse\workspace\Introduction > Example\target\clover\database\clover_coverage.db'. > The file "clover_coverage.db" is created at folder "target\clover\database" > -- > When I am using AspectJ plugin with no preGoal for "java:compile" the Clover > report is generated properly. > -- > The MPCLOVER-27 issue reports this same problem, but did not provide data to > reproduce it. > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-83) Wrong username during release:prepare tagging
[ http://jira.codehaus.org/browse/MRELEASE-83?page=all ] Brett Porter updated MRELEASE-83: - Fix Version: 2.0-beta-4 > Wrong username during release:prepare tagging > - > > Key: MRELEASE-83 > URL: http://jira.codehaus.org/browse/MRELEASE-83 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Niclas Hedhman > Fix For: 2.0-beta-4 > > > If I my Svn repository requires a different username than the login name, and > I issue >mvn [EMAIL PROTECTED] release:prepare > The first phase (checking in modified POMs) will succeed with that username. > Then somewhere between that point and writing out the release.properties > file, the user name falls back to the login name (in my case "niclas"), which > is written into the release.properties file, and used during the tagging of > the repository. > Now, looking at the source, I think that is unwise to keep a username both in > the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that > there is some type of sequencing problem in there. > WORKAROUND; > Before starting the release:prepare, create a release.properties file > manually which contains > [EMAIL PROTECTED] > and everything will work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-41) release:prepare fails when CVS tagging gives a warning
[ http://jira.codehaus.org/browse/MRELEASE-41?page=all ] Brett Porter updated MRELEASE-41: - Fix Version: 2.0-beta-4 > release:prepare fails when CVS tagging gives a warning > -- > > Key: MRELEASE-41 > URL: http://jira.codehaus.org/browse/MRELEASE-41 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: Maven 2, release plugin version 2.0-beta-3. Scm url is > scm:cvs:ext:[EMAIL PROTECTED]:_CVSROOT_. The host that runs the release is on > Linux and the CVS repository is on Linux. > Reporter: Ørjan Austvold > Fix For: 2.0-beta-4 > > > The release:prepare target fails with > [INFO] Tagging release with the label ADMIN_CONSOLE_3_2_8. > [EMAIL PROTECTED]'s password: > Provider message: > The cvs tag command failed. > Command output: > Warning: No xauth data; using fake authentication data for X11 forwarding. > cvs tag: pom.xml is locally modified > Looking through the code it seems like the release fails beacuse the cvs > command returns a status different from successful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-91) Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs
[ http://jira.codehaus.org/browse/MRELEASE-91?page=all ] Brett Porter updated MRELEASE-91: - Fix Version: 2.0-beta-4 > Updating of dependencyManagement inconsistent with updating of dependencies > with regard to SNAPSHOTs > > > Key: MRELEASE-91 > URL: http://jira.codehaus.org/browse/MRELEASE-91 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: maven 2.0.4, win XP > Reporter: Marcel Schutte > Fix For: 2.0-beta-4 > Attachments: release.patch > > > The mechanism in release:prepare for creating the new development version of > POM's handles snapshots that are part of the current reactor build > differently for dependencyManagement and for dependencies. > A snapshot version in a dependencies section will be updated to the next > development version whereas one in dependencyManagement won't. > The attached patch will change this behavior. It will update a snapshot > version under dependencyManagement if and only if it is part of the current > reactor build. > Note that dependencies cannot contain snapshot versions that are not part of > the current reactor, but dependencyManagement can. I suggest to forbid this > too. > A second suggestion is to introduce a parameter to control the updating of > snapshot dependencies in both dependencyManagement and dependencies sections. > Either leave them at the released version or update them to the new > development version. This touches on the discussion in MRELEASE-36 about the > developer having to knowingly choose to use a new development version. I > would be fine with using a parameter to select the behavior as obtained with > my patch. My central point is that dependencyManagement and dependencies > snapshots should behave the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=all ] Brett Porter updated MRELEASE-6: Fix Version: 2.0-beta-4 > Multiproject Release: No check in > - > > Key: MRELEASE-6 > URL: http://jira.codehaus.org/browse/MRELEASE-6 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: Windows XP, Eclipse Workspace > Reporter: Bernd Mau > Priority: Critical > Fix For: 2.0-beta-4 > > > I tried to release a multiproject with 5 modules (on a Branch). Well, > the POMs of all modules are changed and there are some dependencies > which have been updated correctly. But only the master has been checked > in correctly. > I'm changed the recommended layout, to fit in an eclipse workspace. I > have one master at the same level as the other modules. > The module section of the master pom.xml: > > ../hhla.library.pom > ../hhla.library.site > ../hhla.lang > ../hhla.common.log4jx > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-45) release plugin removes xml comments and attributes
[ http://jira.codehaus.org/browse/MRELEASE-45?page=all ] Brett Porter updated MRELEASE-45: - Fix Version: 2.0-beta-4 > release plugin removes xml comments and attributes > -- > > Key: MRELEASE-45 > URL: http://jira.codehaus.org/browse/MRELEASE-45 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Vincent Siveton > Fix For: 2.0-beta-4 > > > I noticed that maven-release-plugin has removed some elements in pom.xml > files, during beta1 transition : > * xml encoding; > * Apache license; > * xsd reference (Regression bug MNG-596) > Try a svn diff between 289378 and 289532 revisions for > components\maven-plugins\maven-site-plugin\pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-95) Exception if version has no minor number
[ http://jira.codehaus.org/browse/MRELEASE-95?page=all ] Brett Porter updated MRELEASE-95: - Fix Version: 2.0-beta-4 > Exception if version has no minor number > > > Key: MRELEASE-95 > URL: http://jira.codehaus.org/browse/MRELEASE-95 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-3 > Reporter: Joerg Schaible > Fix For: 2.0-beta-4 > > > The plugin fails if the snapshot version doe not contain a minor number, e.g. > 1-SNAPSHOT. It should simply increase the major number, but fails with > StringIndexOutOfBoundsException: > %< > $ LANG=C mvn release:prepare > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'release'. > [INFO] > > [INFO] Building Elsag Master Project > [INFO]task-segment: [release:prepare] (aggregator-style) > [INFO] > > [INFO] [release:prepare] > [INFO] What tag name should be used? > v_1 > [INFO] Verifying there are no local modifications ... > [INFO] Checking lineage for snapshots ... > [INFO] Checking dependencies for snapshots ... > [INFO] Checking plugins for snapshots ... > [INFO] What is the release version for 'foo:master'? [1] > [INFO] Checking in modified POMs > [INFO] Tagging release with the label v_1. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] String index out of range: 2 > [INFO] > > [INFO] Trace > java.lang.StringIndexOutOfBoundsException: String index out of range: 2 > at java.lang.String.substring(String.java:1441) > at > org.apache.maven.plugins.release.helpers.ProjectVersionResolver.incrementVersion(ProjectVersionResolver.java:124) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:257) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 8 seconds > [INFO] Finished at: Tue Apr 18 13:19:22 CEST 2006 > [INFO] Final Memory: 3M/6M > [INFO] > > %< -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-76) Use new ScmProviderRepository.setPersistCheckout flag
[ http://jira.codehaus.org/browse/MRELEASE-76?page=all ] Brett Porter updated MRELEASE-76: - Fix Version: 2.0-beta-4 > Use new ScmProviderRepository.setPersistCheckout flag > - > > Key: MRELEASE-76 > URL: http://jira.codehaus.org/browse/MRELEASE-76 > Project: Maven 2.x Release Plugin > Type: Improvement > Reporter: Mike Perham > Fix For: 2.0-beta-4 > > > This is needed for decent Perforce and ClearCase support of the release > process. The release plugin should set this flag to false before checking > out the code upon release:perform. > See SCM-113 for more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-92) PerformMojo throws an error if there are no process args
[ http://jira.codehaus.org/browse/MRELEASE-92?page=all ] Brett Porter updated MRELEASE-92: - Fix Version: 2.0-beta-4 > PerformMojo throws an error if there are no process args > > > Key: MRELEASE-92 > URL: http://jira.codehaus.org/browse/MRELEASE-92 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: winxp, maven 2.0.4 > Reporter: Daun DeFrance > Fix For: 2.0-beta-4 > Attachments: MRELEASE-92.patch > > > While reading the process, PerformReleasMojo.getSystemEnvVars looks for an > '=' and then tries to get substrings on either side to form key/value > properties. Under my environment, the index of '=' is -1 and the code does > not guard before trying to grab a substring with this index. > I will attach the diff file of the (very minor) fix to workaround this > problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-63) Error when trying release:prepare a second time
[ http://jira.codehaus.org/browse/MRELEASE-63?page=all ] Brett Porter updated MRELEASE-63: - Fix Version: 2.0-beta-4 > Error when trying release:prepare a second time > --- > > Key: MRELEASE-63 > URL: http://jira.codehaus.org/browse/MRELEASE-63 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: 2.1-snapshot (note: the build number is still missing from "mvn > --version" so it's hard to report which snapsot version it is) > Reporter: Vincent Massol > Assignee: Jason van Zyl > Fix For: 2.0-beta-4 > > > I've ran release:prepare a first time and it failed on authentication. When > trying to run it a second time I got: > C:\dev\maven\trunks\plugins\maven-clover-plugin>mvn release:prepare > -Dusername=vmassol > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'release'. > [INFO] > > [INFO] Building Maven Clover Plugin > [INFO]task-segment: [release:prepare] (aggregator-style) > [INFO] > > [WARNING] > Artifact junit:junit:jar:3.8.1 retains local scope 'test' overriding > broader scope 'compile' > given by a dependency. If this is not intended, modify or remove the > local scope. > [INFO] [release:prepare] > [INFO] Checking in modified POMs > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugins.release.helpers.ScmHelper.checkin(ScmHelper.java:233) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.checkIn(PrepareReleaseMojo.java:1305) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.checkInRelease(PrepareReleaseMojo.java:1212) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:268) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:216) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Mon Dec 26 09:38:49 CET 2005 > [INFO] Final Memory: 3M/7M > [INFO] > > Manually removing the release.properties file fixed the pb. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-43) Release plug-in did not add the tag to the end of tagBase
[ http://jira.codehaus.org/browse/MRELEASE-43?page=all ]
Brett Porter updated MRELEASE-43:
-
Fix Version: 2.0-beta-4
> Release plug-in did not add the tag to the end of tagBase
> -
>
> Key: MRELEASE-43
> URL: http://jira.codehaus.org/browse/MRELEASE-43
> Project: Maven 2.x Release Plugin
> Type: Bug
> Environment: Win XP, sp2
> Reporter: Michael Fiedler
> Fix For: 2.0-beta-4
>
>
> The release:prepare seemed to work fine until the Continuum build complained.
> I found that my scm/connection and scm/developerConnection did not look the
> way I expected. The tag name provided at the prompt did not get appended to
> tagBase, it was placed after tags. Subversion did end up the way I expected:
> http://host/dir/tags/modules/1.0-QA/
>
> ...
>
> scm:svn:http://host/dir/tags/1.0-QA/modules
> scm:svn:http://${release_ui}:[EMAIL
> PROTECTED]/dir/tags/1.0-QA/modules
> http://host/dir/tags/1.0-QA/modules
>
>
>
>
>
> maven-release-plugin
>
> http://host/dir/tags/modules
> ${release_ui}
> ${release_pw}
>
>
>
>
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-71) build.pluginMangement.plugin is growing after each release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-71?page=all ] Brett Porter updated MRELEASE-71: - Fix Version: 2.0-beta-4 > build.pluginMangement.plugin is growing after each release:prepare > -- > > Key: MRELEASE-71 > URL: http://jira.codehaus.org/browse/MRELEASE-71 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: xp, 2.0.2-snapshot, latest release plugin from svn > Reporter: Dan Tran > Fix For: 2.0-beta-4 > > > it seems the plugin list is double after each release:prepare -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-97) make release:perform upload progress overwrite the previous xxK/yyK uploaded line
[ http://jira.codehaus.org/browse/MRELEASE-97?page=all ] Brett Porter updated MRELEASE-97: - Fix Version: 2.0-beta-4 > make release:perform upload progress overwrite the previous xxK/yyK uploaded > line > - > > Key: MRELEASE-97 > URL: http://jira.codehaus.org/browse/MRELEASE-97 > Project: Maven 2.x Release Plugin > Type: Improvement > Versions: 2.0-beta-4 > Environment: maven 2.0.4, head versions of all plugins, win xp, sun jdk > 1.5.0_06 > Reporter: Marcel Schutte > Fix For: 2.0-beta-4 > Attachments: ReleaseTestWEB.zip, maven-release-plugin.diff, plexus-utils.diff > > > The current CommandLineUtils.executeCommandLine() in plexus-utils uses the > StreamPumper class to copy the output of the 'mvn deploy' call. Because this > class is line based, it cannot distinguish between a standard newline and a > '\r'. Because of this the upload progress doesn't overwrite itself as the > download progress usually does, but writes each step on a new line (see > MRELEASE-55). > I've created 2 patches, one for the release-plugin itself and one for > plexus-utils. I'm submitting the plexus-utils patch here as well, because of > the direct relation with this report. > To test, replace the plexus-utils-1.1.jar in /core with the newly > built plexus-utils-1.2-SNAPSHOT.jar. After this, import the web project in > ReleaseTestWEB.zip into CVS and update the scm url in the pom. Perform a > release:prepare and release:perform and verify that the upload counter stays > on the same line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-58) Update the release.properties if pom.xml have been updated (SCM
[ http://jira.codehaus.org/browse/MRELEASE-58?page=all ] Brett Porter updated MRELEASE-58: - Fix Version: 2.0-beta-4 > Update the release.properties if pom.xml have been updated (SCM > > > Key: MRELEASE-58 > URL: http://jira.codehaus.org/browse/MRELEASE-58 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Eric Hartmann > Fix For: 2.0-beta-4 > > > I experienced the same troubles as described in > http://www.nabble.com/-M2-What-is-wrong-with-my-scm-url--t480810.html#a1308659 > . > The build error print : > Embedded error: Can't load the scm provider. > No such provider: 'rver'. > And with mvn -X give me : > [DEBUG] Artifact resolved > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-4-SNAPSHOT:prepare' > --> > [DEBUG] (f) basedir = /projects/jing-trang > [DEBUG] (f) generateReleasePoms = false > [DEBUG] (f) interactive = true > [DEBUG] (f) localRepository = [local] -> > file:///home/ehartmann/.m2/repository > [DEBUG] (f) reactorProjects = [EMAIL PROTECTED] > [DEBUG] (f) resume = true > [DEBUG] (f) settings = [EMAIL PROTECTED] > [DEBUG] (f) tagBase = ../tags > [DEBUG] (f) urlScm = cvs:pserver:cvs.sharedvalue.com:/opt/cvs/:jing-trang > [DEBUG] -- end configuration -- > Unfortunately I was not aware of the url is taken in release.properties > (since the urlScm is right in the debug log) and look for this issue for a > couple of hours before finding the explanation in the mailing list. > It may be usefull to recreate release.properties if pom.xml have been updated > since it's creation and/or log the information taken in release.properties to > give a hint to developers (who have not carefully read > http://maven.apache.org/scm as myself :-)) that made an error in the scm url. > I create a new bug report instead of http://jira.codehaus.org/browse/MNG-1105 > as I think it's not quite the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-61) Ability to pass all prompted information as parameters in release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-61?page=all ] Brett Porter updated MRELEASE-61: - Fix Version: 2.0-beta-4 > Ability to pass all prompted information as parameters in release:prepare > - > > Key: MRELEASE-61 > URL: http://jira.codehaus.org/browse/MRELEASE-61 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Yann Le Du > Priority: Minor > Fix For: 2.0-beta-4 > > > In release:prepare, it would be nice that all prompted information can also > be passed as parameters : > * tag name (already available, -Dtag) > * release version > * new development version > It would allow to call the plugin in real non-interactive mode - that is, > without being forced to accept default values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-30) release:prepare changes incorrectly tag pom scm if tagbase not standard
[ http://jira.codehaus.org/browse/MRELEASE-30?page=all ] Brett Porter updated MRELEASE-30: - Fix Version: 2.0-beta-4 > release:prepare changes incorrectly tag pom scm if tagbase not standard > --- > > Key: MRELEASE-30 > URL: http://jira.codehaus.org/browse/MRELEASE-30 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Yann Le Du > Fix For: 2.0-beta-4 > > > /COMMON/trunk/maven-plugins/maven-deps-plugin/pom.xml : > > > scm:svn:svn://host:3691/COMMON/trunk/maven-plugins/maven-deps-plugin/ > > scm:svn:svn://host:3691/COMMON/trunk/maven-plugins/maven-deps-plugin/ > > http://host.corp.com/viewcvs/COMMON/trunk/maven-plugins/maven-deps-plugin/ > > [...] > maven-release-plugin > 2.0-beta-2 > > svn://host:3691/COMMON/tags/ > m2 release:prepare tags creates correctly a tag in > /COMMON/tags/maven-deps-plugin_V1.0.0, but the tag pom.xml contains : > > > scm:svn:svn://host:3691/COMMON/tags/maven-deps-plugin_V1.0.0/maven-plugins/maven-deps-plugin/ > > scm:svn:svn://host:3691/COMMON/tags/maven-deps-plugin_V1.0.0/maven-plugins/maven-deps-plugin/ > > http://host.corp.com/viewcvs/COMMON/tags/maven-deps-plugin_V1.0.0/maven-plugins/maven-deps-plugin/ > > ...that is, maven-plugins/maven-deps-plugin/ is concatenated at the end of > URLs, although we don't expect it. > The tag release-pom.xml and repo POMs contain correct trunk URLs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-16) release-pom is changed too much
[ http://jira.codehaus.org/browse/MRELEASE-16?page=all ] Brett Porter updated MRELEASE-16: - Fix Version: 2.0-beta-4 > release-pom is changed too much > --- > > Key: MRELEASE-16 > URL: http://jira.codehaus.org/browse/MRELEASE-16 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Brett Porter > Fix For: 2.0-beta-4 > > > this needs a full review. > Expressions are populated that shouldn't be (only external settings should be > filled in, but not those like basedir or are otherwise path dependant like > project.file...) > basically need to use the pre-interpolation, post inheritence pom... or can > we live with the original one without inheritence and just fill in resolved > versions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-27) Insufficient information when SCM URL is wrong
[ http://jira.codehaus.org/browse/MRELEASE-27?page=all ] Brett Porter updated MRELEASE-27: - Fix Version: 2.0-beta-4 > Insufficient information when SCM URL is wrong > -- > > Key: MRELEASE-27 > URL: http://jira.codehaus.org/browse/MRELEASE-27 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Jochen Wiedmann > Fix For: 2.0-beta-4 > > > If the method CvsScmProvider.parseScmUrl returns an error message, then an > ScmRepositoryException is thrown with additional messages. These messages > aren't made available to the user, although the really should be. > Two possible solutions: > - Override ScmRepositoryException.getMessage() > - Use the additional information when catching the exception. > To see the issue, try "mvn release:prepare" with an invalid URL like > "scm:cvs:foobar". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-90) Exception if version is SNAPSHOT
[ http://jira.codehaus.org/browse/MRELEASE-90?page=all ] Brett Porter updated MRELEASE-90: - Fix Version: 2.0-beta-4 > Exception if version is SNAPSHOT > > > Key: MRELEASE-90 > URL: http://jira.codehaus.org/browse/MRELEASE-90 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-3 > Reporter: Joerg Schaible > Fix For: 2.0-beta-4 > > > If the project has a very simple version scheme (i.e. only a simple number) > and has therefore set the verstion tag to "SNAPSHOT", the plugin fails with a > StringIndexOutOfRange exception: > [INFO] [release:prepare] > [INFO] Verifying there are no local modifications ... > [INFO] Checking lineage for snapshots ... > [INFO] Checking dependencies for snapshots ... > [INFO] Checking plugins for snapshots ... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] String index out of range: -1 > [INFO] > > [INFO] Trace > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at java.lang.String.substring(String.java:1444) > at > org.apache.maven.plugins.release.helpers.ProjectVersionResolver.resolveVersion(ProjectVersionResolver.java:61) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:219) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-9) default version for the release, but not the development
[ http://jira.codehaus.org/browse/MRELEASE-9?page=all ] Brett Porter updated MRELEASE-9: Fix Version: 2.0-beta-4 > default version for the release, but not the development > > > Key: MRELEASE-9 > URL: http://jira.codehaus.org/browse/MRELEASE-9 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: Win XP, sp2 > Reporter: Michael Fiedler > Priority: Minor > Fix For: 2.0-beta-4 > > >When the prepare goal of release is executed, a default exists for the > release version of each pom.xml. However, the development version prompt did > not have a default listed in all cases. Only one had a default. Is this > considered a bug? If not, I would like to request/suggest having a default > for > all . >I am using maven2. > console: > C:\...\modules>mvn release:prepare > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] modules > [INFO] x > [INFO] y > [INFO] z > [INFO] Searching repository for plugin with prefix: 'release'. > [INFO] > > [INFO] Building modules > [INFO]task-segment: [release:prepare] (aggregator-style) > [INFO] > > [INFO] snapshot com.werner:x:1.2-SNAPSHOT: checking for updates from middle > tier > [INFO] [release:prepare] > [INFO] What tag name should be used? > QA > [INFO] Verifying there are no local modifications ... > [INFO] Checking lineage for snapshots ... > [INFO] Checking dependencies for snapshots ... > [INFO] Checking plugins for snapshots ... > [INFO] What is the release version for 'com.werner:modules'? [1.0.1] > [INFO] Checking lineage for snapshots ... > [INFO] Checking dependencies for snapshots ... > [INFO] Checking plugins for snapshots ... > [INFO] What is the release version for 'com.werner:x'? [1.2] > [INFO] Checking lineage for snapshots ... > [INFO] Checking dependencies for snapshots ... > [INFO] Checking plugins for snapshots ... > [INFO] What is the release version for 'com.werner:y'? [1.0.1] > [INFO] Checking lineage for snapshots ... > [INFO] Checking dependencies for snapshots ... > [INFO] Checking plugins for snapshots ... > [INFO] What is the release version for 'com.werner:z'? [1.0.1] > [INFO] Checking in modified POMs > [INFO] Tagging release with the label QA. > [INFO] What is the new development version for 'com.werner:modules'? [] > [INFO] What is the new development version for 'com.werner:x'? [1.3-SNAPSHOT] > [INFO] What is the new development version for 'com.werner:y'? [] > [INFO] What is the new development version for 'com.werner:z'? [] > [INFO] Checking in development POMs > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-75) Release perform injects parent pom into child and checks in for next development iteration
[ http://jira.codehaus.org/browse/MRELEASE-75?page=all ] Brett Porter updated MRELEASE-75: - Fix Version: 2.0-beta-4 > Release perform injects parent pom into child and checks in for next > development iteration > -- > > Key: MRELEASE-75 > URL: http://jira.codehaus.org/browse/MRELEASE-75 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Brian Fox > Priority: Blocker > Fix For: 2.0-beta-4 > Attachments: release-fail.zip > > > My child poms effectively get merged with the parents and checked in for the > next development iteration. This basically breaks all inheritance completely > and I end up doing more work undoing it than if I just did the release by > hand. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-74) release plugin removes sections in the pom.xml ???
[ http://jira.codehaus.org/browse/MRELEASE-74?page=all ] Brett Porter updated MRELEASE-74: - Fix Version: 2.0-beta-4 > release plugin removes sections in the pom.xml ??? > -- > > Key: MRELEASE-74 > URL: http://jira.codehaus.org/browse/MRELEASE-74 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: solaris 9 > Reporter: Olivier Lamy > Priority: Blocker > Fix For: 2.0-beta-4 > Attachments: pom.diff > > > My reporting section is section is removed by the release:plugin. > Attached file contains the cvs diff. > Is it due to false in all reporting plugin ? > Thanks, > Olivier -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-37) Module dependancies with inherited versions are updated to have versions
[ http://jira.codehaus.org/browse/MRELEASE-37?page=all ] Brett Porter updated MRELEASE-37: - Fix Version: 2.0-beta-4 > Module dependancies with inherited versions are updated to have versions > > > Key: MRELEASE-37 > URL: http://jira.codehaus.org/browse/MRELEASE-37 > Project: Maven 2.x Release Plugin > Type: Bug > Reporter: Greg Wilkins > Priority: Minor > Fix For: 2.0-beta-4 > > > if intermodule dependancies are inherited in a module pom (ie not listed in > the pom), the release:prepare target updates the poms to have explicit > versions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-70) ${version} in dependencyManagement is replaced after release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-70?page=all ]
Brett Porter updated MRELEASE-70:
-
Fix Version: 2.0-beta-4
> ${version} in dependencyManagement is replaced after release:prepare
>
>
> Key: MRELEASE-70
> URL: http://jira.codehaus.org/browse/MRELEASE-70
> Project: Maven 2.x Release Plugin
> Type: Bug
> Environment: xp, 2.0.2-SNAPSHOT, last release plugin from svn
> Reporter: Dan Tran
> Fix For: 2.0-beta-4
>
>
> In my top pom, I use ${version} to refer as the same version of the pom in my
> dependencyMangement. However after release:prepare,
> ${version} is replaced at the release version. and there more my
> dependency-maven-plugin:copy mojo, which relies heavily to dependencyMangement
> to fill in the missing version, breaks. It nows fills in the wrong version.
> So the work around is that I need to manually change it back to ${version}
> after each daily release.
> here is an example of my dependencyMangement
>
> ...
>
> com.borland.optimizeit.components
> optimizeit
> ${version}
> zip
>
>
> com.borland.optimizeit.components
> agent-win32
> ${version}
> zip
>
> ...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (WAGON-43) wagon-ftp sometimes does not build due to socket errors in tests
wagon-ftp sometimes does not build due to socket errors in tests Key: WAGON-43 URL: http://jira.codehaus.org/browse/WAGON-43 Project: wagon Type: Bug Versions: 1.0-alpha-7 Environment: linux, maven 2.0.4 Reporter: Henry S. Isidro Priority: Minor The wagon-ftp provider build sometimes do not continue due to a SocketException in the unit test. This message is displayed several times: [ERROR] Exception accepting connection java.net.SocketException: Socket is closed at java.net.ServerSocket.accept(ServerSocket.java:417) at org.apache.avalon.cornerstone.blocks.connection.Connection.run(Connection.java:134) at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:90) at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:136) There are times though that the build will succeed so this seems to be an inconsistent occurrence. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-41) Wagon SCM does not add correctly new files
[ http://jira.codehaus.org/browse/WAGON-41?page=all ] Carlos Sanchez updated WAGON-41: Priority: Critical (was: Major) Fix Version: 1.0-alpha-7 > Wagon SCM does not add correctly new files > -- > > Key: WAGON-41 > URL: http://jira.codehaus.org/browse/WAGON-41 > Project: wagon > Type: Bug > Versions: 1.0-alpha-7 > Reporter: Carlos Sanchez > Priority: Critical > Fix For: 1.0-alpha-7 > > > If the directory to deploy the site to exists, but the files don't, the > deploy doesn't add new files. > The problem is that tries to add files target/checkout/* using > target/checkout as working dir, so the scm add fails, but Wagon doesn't check > for failure in the add command, so neither does it deploy or show the error. > We need to: > cover that case in unit tests (better if done at wagon-test level) > make wagon fail when the add command fails > make wagon add the right file name relative from the working dir -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Carlos Sanchez updated WAGON-19: Priority: Critical (was: Major) Fix Version: 1.0-alpha-7 > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-alpha-7 > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=all ] Carlos Sanchez updated WAGON-40: Priority: Critical (was: Major) Fix Version: 1.0-alpha-7 > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Priority: Critical > Fix For: 1.0-alpha-7 > Attachments: site.error.txt > > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-42) wagon-scm (svn provider) - large paths under windows breaks download.
[ http://jira.codehaus.org/browse/WAGON-42?page=all ] Carlos Sanchez updated WAGON-42: Priority: Critical (was: Major) Fix Version: 1.0-alpha-7 > wagon-scm (svn provider) - large paths under windows breaks download. > - > > Key: WAGON-42 > URL: http://jira.codehaus.org/browse/WAGON-42 > Project: wagon > Type: Bug > Versions: 1.0-alpha-6 > Reporter: Joakim Erdfelt > Priority: Critical > Fix For: 1.0-alpha-7 > > > I have a deep path in windows, plus a repository housed in svn. > When performing a 'mvn compile', it fails with not finding the artifact. > Using mvn --debug shows no error message from wagon-scm (svn). > If I go into the target/checkout/ directory, i see an empty directory > with the '.svn' working directory. > performing a 'svn update .' in that directory reveals the reason ... > [EMAIL PROTECTED] > /c/code/mergere/amex/AXP-EntBuildEnv/tools/branches/mergere-discovery-wizard/mergere-discovery-core/target/checkout/org/apache/maven/repository/maven-repository-indexer/1.0-SNAPSHOT > $ svn update . > svn: Can't open file > '.svn/text-base/maven-repository-indexer-1.0-20060418.201022-1.jar.md5.svn-base': > File name too long > I think a general "if windows, and path exceeds maximum, throw error before > attempting process' kind of functionality needs to exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-33) FileWagon#putDirectory() fails in HP-UX if destinationDirectory is "."
[ http://jira.codehaus.org/browse/WAGON-33?page=all ] Carlos Sanchez updated WAGON-33: Fix Version: 1.0-alpha-7 > FileWagon#putDirectory() fails in HP-UX if destinationDirectory is "." > -- > > Key: WAGON-33 > URL: http://jira.codehaus.org/browse/WAGON-33 > Project: wagon > Type: Bug > Versions: 1.0-alpha-6 > Environment: HP-UX. There has been reports on linux as well. > Reporter: Shinobu Kawai > Priority: Critical > Fix For: 1.0-alpha-7 > Attachments: WAGON-30.patch > > > WAGON-30 is not solved for the HP-UX platform. > Attached is a dirty quick-fix. Probably better if we used > File#getCanonicalFile(), but we will need to handle IOException for that. > (Of course, you can just wrap it and throw it) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-36) An exception is throwed when the http response code is 201
[ http://jira.codehaus.org/browse/WAGON-36?page=all ]
Carlos Sanchez updated WAGON-36:
Fix Version: 1.0-alpha-7
> An exception is throwed when the http response code is 201
> --
>
> Key: WAGON-36
> URL: http://jira.codehaus.org/browse/WAGON-36
> Project: wagon
> Type: Bug
> Versions: 1.0-alpha-6
> Reporter: Alexandre Poitras
> Priority: Minor
> Fix For: 1.0-alpha-7
>
>
> The put method of the LightweightHttpWagon class throw an exception whener
> the http response code is 201. The 201 code indicate the PUT method has
> completed successfully in a WebDav environment.
> The problem comes from here :
> if ( putConnection.getResponseCode() != HttpURLConnection.HTTP_OK
> )
> {
> throw new TransferFailedException(
> "Unable to transfer file. HttpURLConnection returned the
> response code: " +
> putConnection.getResponseCode() );
> }
>
> An exception is thrown whenever the Http code is different from 200 wich is
> not good.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-43) wagon-ftp sometimes does not build due to socket errors in tests
[ http://jira.codehaus.org/browse/WAGON-43?page=all ] Carlos Sanchez updated WAGON-43: Fix Version: 1.0-alpha-7 > wagon-ftp sometimes does not build due to socket errors in tests > > > Key: WAGON-43 > URL: http://jira.codehaus.org/browse/WAGON-43 > Project: wagon > Type: Bug > Versions: 1.0-alpha-7 > Environment: linux, maven 2.0.4 > Reporter: Henry S. Isidro > Priority: Minor > Fix For: 1.0-alpha-7 > > > The wagon-ftp provider build sometimes do not continue due to a > SocketException in the unit test. This message is displayed several times: > [ERROR] Exception accepting connection > java.net.SocketException: Socket is closed > at java.net.ServerSocket.accept(ServerSocket.java:417) > at > org.apache.avalon.cornerstone.blocks.connection.Connection.run(Connection.java:134) > at > org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:90) > at > org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:136) > There are times though that the build will succeed so this seems to be an > inconsistent occurrence. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-39) scp-external-wagen and ssh using ProxyCommand blacklist repository
[ http://jira.codehaus.org/browse/WAGON-39?page=all ]
Carlos Sanchez updated WAGON-39:
Fix Version: 1.0-alpha-7
> scp-external-wagen and ssh using ProxyCommand blacklist repository
> -
>
> Key: WAGON-39
> URL: http://jira.codehaus.org/browse/WAGON-39
> Project: wagon
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: linux 2.6.15-1.2054_FC5
> client ssh: OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
> server in the middle ssh:OpenSSH_4.2, OpenSSL 0.9.7d 17 Mar 2004
>
> Reporter: M. van der Plas
> Fix For: 1.0-alpha-7
> Attachments: EndsWith.patch
>
>
> I use my laptop to work at the office and at home. The office has a
> repository for inhouse developed projects.
> ssh channles are used to connect with the office repository from home.
> I configured ssh using with a ProcyCommand to tunnel to the subversion
> respository.
> I configured mvn using a home specific settings.xml to use scp-external-ssh
> as the standard ssh wagon cannot handle the ProxyCommand.
> This fails when external 3rd party artifacts and plugins are checked in the
> company repositories.
> Since they are located in the ibiblio central repository the scp command
> fails.
> This is normally not a problem because the Wagons check if the output of the
> copy command is "No such file or directory".
> If so, the artifact is searched in another repository.
> With the introduction of the ProxyCommand this mechanism does not work any
> more.
> ProxyCommand prints "Killed by signal 1" to stderr when the scp command fails.
> See also http://lists.debian.org/debian-ssh/2005/06/msg00074.html for the ssh
> bug.
> The problem is that both
> wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/ScpWagon.java
> (revision 388735)
> and
> wagon-providers/wagon-ssh-external/src/main/java/org/apache/maven/wagon/providers/sshext/ScpExternalWagon.java
> (revision 388735)
> use stderr.endsWith("No such file or directory") while stderr in my case ends
> with "Killed by sgnal 1."
> The problem can be fixed by using indexOf( "No such file or directory") != -1
> instead of the endsWith() call.
> I've implemented this fix and verified that the problem did not occur. The
> patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_63914
]
Dimitry Voytenko commented on MNGECLIPSE-59:
Hi Mark,
I managed to recompile and run the plugin. It works well. But there were couple
issues I ran into:
1) It still crashes inside of Maven2Plugin.getWorkspaceNature() for
"project.getNature" when project is closed. I added check for project's
closed/open status - it was fine.
2) Just to be aware, you had "libraryEntries.add(JavaCore.newProjectEntry(...)"
inside of the if with "("jar".equals(a.getType()) || "zip".equals( a.getType()
)" which was since changed to "artifactLocation.endsWith("jar") ||
artifactLocation.endsWith("zip")". For the obvious reasons your code for adding
project to the classpath is never called now (since location is "pom.xml" in
that case). I had to move it outside of plugin, it was fine as well.
> Allow artifact resolution from workspace projects
> -
>
> Key: MNGECLIPSE-59
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-59
> Project: Maven 2.x Extension for Eclipse
> Type: New Feature
> Components: Dependency Resolver
> Versions: 0.0.4
> Reporter: Leonardo Quijano Vincenzi
> Assignee: Eugene Kuleshov
> Fix For: 1.0.0
> Attachments: ArtifactResolver-try3.patch,
> EclipseArtifactResolver-corrected.patch, EclipseArtifactResolver.patch,
> maven-embedder-2.1-SNAPSHOT-dep.jar
>
>
> Provide artifact resolution from workspace projects, which override the same
> artifact from the local or remote repositories. This would allow to work with
> dependant Eclipse projects without specifying the Eclipse dependency manually.
> The workspace artifact resolution would have to be specified manually, since
> several Maven-Enabled projects in the same workspace could have the same
> artifact and version Id. Or at least automatic resolution with an optional
> override would be nice.
> More comments here:
> http://jira.codehaus.org/browse/MNGECLIPSE-58
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-33) FileWagon#putDirectory() fails in HP-UX if destinationDirectory is "."
[ http://jira.codehaus.org/browse/WAGON-33?page=all ] Carlos Sanchez updated WAGON-33: Component: wagon-file > FileWagon#putDirectory() fails in HP-UX if destinationDirectory is "." > -- > > Key: WAGON-33 > URL: http://jira.codehaus.org/browse/WAGON-33 > Project: wagon > Type: Bug > Components: wagon-file > Versions: 1.0-alpha-6 > Environment: HP-UX. There has been reports on linux as well. > Reporter: Shinobu Kawai > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: WAGON-30.patch > > > WAGON-30 is not solved for the HP-UX platform. > Attached is a dirty quick-fix. Probably better if we used > File#getCanonicalFile(), but we will need to handle IOException for that. > (Of course, you can just wrap it and throw it) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=all ] Carlos Sanchez updated WAGON-40: Component: wagon-file > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Components: wagon-file > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: site.error.txt > > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-42) wagon-scm (svn provider) - large paths under windows breaks download.
[ http://jira.codehaus.org/browse/WAGON-42?page=all ] Carlos Sanchez updated WAGON-42: Component: wagon-scm > wagon-scm (svn provider) - large paths under windows breaks download. > - > > Key: WAGON-42 > URL: http://jira.codehaus.org/browse/WAGON-42 > Project: wagon > Type: Bug > Components: wagon-scm > Versions: 1.0-alpha-6 > Reporter: Joakim Erdfelt > Priority: Critical > Fix For: 1.0-beta-1 > > > I have a deep path in windows, plus a repository housed in svn. > When performing a 'mvn compile', it fails with not finding the artifact. > Using mvn --debug shows no error message from wagon-scm (svn). > If I go into the target/checkout/ directory, i see an empty directory > with the '.svn' working directory. > performing a 'svn update .' in that directory reveals the reason ... > [EMAIL PROTECTED] > /c/code/mergere/amex/AXP-EntBuildEnv/tools/branches/mergere-discovery-wizard/mergere-discovery-core/target/checkout/org/apache/maven/repository/maven-repository-indexer/1.0-SNAPSHOT > $ svn update . > svn: Can't open file > '.svn/text-base/maven-repository-indexer-1.0-20060418.201022-1.jar.md5.svn-base': > File name too long > I think a general "if windows, and path exceeds maximum, throw error before > attempting process' kind of functionality needs to exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-39) scp-external-wagen and ssh using ProxyCommand blacklist repository
[ http://jira.codehaus.org/browse/WAGON-39?page=all ]
Carlos Sanchez updated WAGON-39:
Component: wagon-ssh-external
> scp-external-wagen and ssh using ProxyCommand blacklist repository
> -
>
> Key: WAGON-39
> URL: http://jira.codehaus.org/browse/WAGON-39
> Project: wagon
> Type: Bug
> Components: wagon-ssh-external
> Versions: 1.0-alpha-6
> Environment: linux 2.6.15-1.2054_FC5
> client ssh: OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
> server in the middle ssh:OpenSSH_4.2, OpenSSL 0.9.7d 17 Mar 2004
>
> Reporter: M. van der Plas
> Fix For: 1.0-beta-1
> Attachments: EndsWith.patch
>
>
> I use my laptop to work at the office and at home. The office has a
> repository for inhouse developed projects.
> ssh channles are used to connect with the office repository from home.
> I configured ssh using with a ProcyCommand to tunnel to the subversion
> respository.
> I configured mvn using a home specific settings.xml to use scp-external-ssh
> as the standard ssh wagon cannot handle the ProxyCommand.
> This fails when external 3rd party artifacts and plugins are checked in the
> company repositories.
> Since they are located in the ibiblio central repository the scp command
> fails.
> This is normally not a problem because the Wagons check if the output of the
> copy command is "No such file or directory".
> If so, the artifact is searched in another repository.
> With the introduction of the ProxyCommand this mechanism does not work any
> more.
> ProxyCommand prints "Killed by signal 1" to stderr when the scp command fails.
> See also http://lists.debian.org/debian-ssh/2005/06/msg00074.html for the ssh
> bug.
> The problem is that both
> wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/ScpWagon.java
> (revision 388735)
> and
> wagon-providers/wagon-ssh-external/src/main/java/org/apache/maven/wagon/providers/sshext/ScpExternalWagon.java
> (revision 388735)
> use stderr.endsWith("No such file or directory") while stderr in my case ends
> with "Killed by sgnal 1."
> The problem can be fixed by using indexOf( "No such file or directory") != -1
> instead of the endsWith() call.
> I've implemented this fix and verified that the problem did not occur. The
> patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-41) Wagon SCM does not add correctly new files
[ http://jira.codehaus.org/browse/WAGON-41?page=all ] Carlos Sanchez updated WAGON-41: Component: wagon-scm > Wagon SCM does not add correctly new files > -- > > Key: WAGON-41 > URL: http://jira.codehaus.org/browse/WAGON-41 > Project: wagon > Type: Bug > Components: wagon-scm > Versions: 1.0-beta-1 > Reporter: Carlos Sanchez > Priority: Critical > Fix For: 1.0-beta-1 > > > If the directory to deploy the site to exists, but the files don't, the > deploy doesn't add new files. > The problem is that tries to add files target/checkout/* using > target/checkout as working dir, so the scm add fails, but Wagon doesn't check > for failure in the add command, so neither does it deploy or show the error. > We need to: > cover that case in unit tests (better if done at wagon-test level) > make wagon fail when the add command fails > make wagon add the right file name relative from the working dir -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
