[jira] (MWAR-278) Overlay Task execution fails in windows with java.io.IOException[The filename, directory name, or volume label syntax is incorrect], when targetPath is present

[Tony Kollamparambil (JIRA)]

 [ 
https://jira.codehaus.org/browse/MWAR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tony Kollamparambil updated MWAR-278:
-

Attachment: Overlay.tar

Please find the attached tar file.We need to deploy both common-rest.war and 
apps-rest.war into one maven-tomcat container without fusing it together.



> Overlay Task execution fails in windows with java.io.IOException[The 
> filename, directory name, or volume label syntax is incorrect], when 
> targetPath is present
> ---
>
> Key: MWAR-278
> URL: https://jira.codehaus.org/browse/MWAR-278
> Project: Maven 2.x WAR Plugin
>  Issue Type: Bug
>  Components: overlay
>Affects Versions: 2.2
> Environment: Windows
>Reporter: Tony Kollamparambil
> Attachments: Overlay.tar
>
>
> Thanks for introducing the "Overlay concept", which is very helpful. we have 
> a scenario in which we need to overlay a war file over the other. 
> maven install is failing with java.io exception when we build the module in 
> WINDOWS with some path in the overlays:overlay:targetpath tag(its works fine 
> in the mac/linux/unix/solaris). 
> Trace : 
> ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project 
> xx: Failed to copy file for overlay [ id xxx:]: The filename, 
> directory name, or volume label syntax is incorrect -> [Help 1] 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on 
> project xxx-: Failed to copy file for overlay [ id xxx:]. 
> Root Cause: 
> As per the analysis that we had performed, its a code bug. Please refer line# 
> 84-88 present in the 
> http://code.google.com/p/maven-alfresco-archetypes/source/browse/trunk/plugins/maven-amp-plugin/src/main/java/org/alfresco/maven/plugin/amp/packaging/OverlayPackagingTask.java?r=127.
>  
> ie; 
>  String targetPath = overlay.getTargetPath(); 
> if (!targetPath.endsWith( "/" )) 
> { 
> targetPath = targetPath + "/"; 
> } 
> by considering the above code snippet as a source of truth, windows will not 
> recognize the forward slash ("/") as a valid file separator. file separator 
> would vary from OS to OS, and hence It must not be hardcoded(it works fine in 
> linux and mac, since the file separator for these operating systems are "/"). 
> System.getProperties("file.separator") can be used for computing the file 
> separator during runtime. Please do the needful. Thanks in advance 
> Stack Trace : 
> [DEBUG] OverlayPackagingTask performPackaging overlay.getTargetPath() 
> C:\projects\xxx\yy\target 
> [INFO] Processing overlay [ id xxx:] 
> [DEBUG] Overlay [ id xxx:] was already unpacked 
> ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project 
> enrollment-rest: Failed to copy file for overlay [ id xxx:]: The 
> filename, directory name, or volume label syntax is incorrect -> [Help 1] 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on 
> project xxx-: Failed to copy file for overlay [ id xxx:]. 
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>  
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) 
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) 
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) 
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) 
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 
> 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.

[jira] (MWAR-278) Overlay Task execution fails in windows with java.io.IOException[The filename, directory name, or volume label syntax is incorrect], when targetPath is present

[Tony Kollamparambil (JIRA)]

[ 
https://jira.codehaus.org/browse/MWAR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297661#comment-297661
 ] 

Tony Kollamparambil edited comment on MWAR-278 at 5/2/12 2:14 AM:
--

Please find the attached tar file.
Goal : We need to deploy both common-rest.war and apps-rest.war into one 
maven-tomcat container without fusing it together.
Problem statement : attached project compiles in linux/Mac but not in windows



  was (Author: tkollamp):
Please find the attached tar file.We need to deploy both common-rest.war 
and apps-rest.war into one maven-tomcat container without fusing it together.


  
> Overlay Task execution fails in windows with java.io.IOException[The 
> filename, directory name, or volume label syntax is incorrect], when 
> targetPath is present
> ---
>
> Key: MWAR-278
> URL: https://jira.codehaus.org/browse/MWAR-278
> Project: Maven 2.x WAR Plugin
>  Issue Type: Bug
>  Components: overlay
>Affects Versions: 2.2
> Environment: Windows
>Reporter: Tony Kollamparambil
> Attachments: Overlay.tar
>
>
> Thanks for introducing the "Overlay concept", which is very helpful. we have 
> a scenario in which we need to overlay a war file over the other. 
> maven install is failing with java.io exception when we build the module in 
> WINDOWS with some path in the overlays:overlay:targetpath tag(its works fine 
> in the mac/linux/unix/solaris). 
> Trace : 
> ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project 
> xx: Failed to copy file for overlay [ id xxx:]: The filename, 
> directory name, or volume label syntax is incorrect -> [Help 1] 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on 
> project xxx-: Failed to copy file for overlay [ id xxx:]. 
> Root Cause: 
> As per the analysis that we had performed, its a code bug. Please refer line# 
> 84-88 present in the 
> http://code.google.com/p/maven-alfresco-archetypes/source/browse/trunk/plugins/maven-amp-plugin/src/main/java/org/alfresco/maven/plugin/amp/packaging/OverlayPackagingTask.java?r=127.
>  
> ie; 
>  String targetPath = overlay.getTargetPath(); 
> if (!targetPath.endsWith( "/" )) 
> { 
> targetPath = targetPath + "/"; 
> } 
> by considering the above code snippet as a source of truth, windows will not 
> recognize the forward slash ("/") as a valid file separator. file separator 
> would vary from OS to OS, and hence It must not be hardcoded(it works fine in 
> linux and mac, since the file separator for these operating systems are "/"). 
> System.getProperties("file.separator") can be used for computing the file 
> separator during runtime. Please do the needful. Thanks in advance 
> Stack Trace : 
> [DEBUG] OverlayPackagingTask performPackaging overlay.getTargetPath() 
> C:\projects\xxx\yy\target 
> [INFO] Processing overlay [ id xxx:] 
> [DEBUG] Overlay [ id xxx:] was already unpacked 
> ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project 
> enrollment-rest: Failed to copy file for overlay [ id xxx:]: The 
> filename, directory name, or volume label syntax is incorrect -> [Help 1] 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on 
> project xxx-: Failed to copy file for overlay [ id xxx:]. 
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>  
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) 
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) 
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) 
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.ja

[jira] (MWAR-278) Overlay Task execution fails in windows with java.io.IOException[The filename, directory name, or volume label syntax is incorrect], when targetPath is present

[Tony Kollamparambil (JIRA)]

[ 
https://jira.codehaus.org/browse/MWAR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297661#comment-297661
 ] 

Tony Kollamparambil edited comment on MWAR-278 at 5/2/12 2:17 AM:
--

Please find the attached tar file.
Goal : We need to deploy both common-rest.war and apps-rest.war into one 
maven-tomcat container without fusing it together.
Problem statement : attached project compiles in linux/Mac but not in windows

Please refer to Overlay/apps/pom.xml for more details

  was (Author: tkollamp):
Please find the attached tar file.
Goal : We need to deploy both common-rest.war and apps-rest.war into one 
maven-tomcat container without fusing it together.
Problem statement : attached project compiles in linux/Mac but not in windows


  
> Overlay Task execution fails in windows with java.io.IOException[The 
> filename, directory name, or volume label syntax is incorrect], when 
> targetPath is present
> ---
>
> Key: MWAR-278
> URL: https://jira.codehaus.org/browse/MWAR-278
> Project: Maven 2.x WAR Plugin
>  Issue Type: Bug
>  Components: overlay
>Affects Versions: 2.2
> Environment: Windows
>Reporter: Tony Kollamparambil
> Attachments: Overlay.tar
>
>
> Thanks for introducing the "Overlay concept", which is very helpful. we have 
> a scenario in which we need to overlay a war file over the other. 
> maven install is failing with java.io exception when we build the module in 
> WINDOWS with some path in the overlays:overlay:targetpath tag(its works fine 
> in the mac/linux/unix/solaris). 
> Trace : 
> ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project 
> xx: Failed to copy file for overlay [ id xxx:]: The filename, 
> directory name, or volume label syntax is incorrect -> [Help 1] 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on 
> project xxx-: Failed to copy file for overlay [ id xxx:]. 
> Root Cause: 
> As per the analysis that we had performed, its a code bug. Please refer line# 
> 84-88 present in the 
> http://code.google.com/p/maven-alfresco-archetypes/source/browse/trunk/plugins/maven-amp-plugin/src/main/java/org/alfresco/maven/plugin/amp/packaging/OverlayPackagingTask.java?r=127.
>  
> ie; 
>  String targetPath = overlay.getTargetPath(); 
> if (!targetPath.endsWith( "/" )) 
> { 
> targetPath = targetPath + "/"; 
> } 
> by considering the above code snippet as a source of truth, windows will not 
> recognize the forward slash ("/") as a valid file separator. file separator 
> would vary from OS to OS, and hence It must not be hardcoded(it works fine in 
> linux and mac, since the file separator for these operating systems are "/"). 
> System.getProperties("file.separator") can be used for computing the file 
> separator during runtime. Please do the needful. Thanks in advance 
> Stack Trace : 
> [DEBUG] OverlayPackagingTask performPackaging overlay.getTargetPath() 
> C:\projects\xxx\yy\target 
> [INFO] Processing overlay [ id xxx:] 
> [DEBUG] Overlay [ id xxx:] was already unpacked 
> ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project 
> enrollment-rest: Failed to copy file for overlay [ id xxx:]: The 
> filename, directory name, or volume label syntax is incorrect -> [Help 1] 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on 
> project xxx-: Failed to copy file for overlay [ id xxx:]. 
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>  
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) 
> at org.apache.maven.DefaultMaven.execute(D

[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.

[Mark Struberg (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297663#comment-297663
 ] 

Mark Struberg commented on MRELEASE-723:


This sounds reasonable, I'll give the patch a try today.

> DCVS tagging commands should store the tag-name (or hash) in the the 
> //project/scm/tag element.
> ---
>
> Key: MRELEASE-723
> URL: https://jira.codehaus.org/browse/MRELEASE-723
> Project: Maven 2.x Release Plugin
>  Issue Type: New Feature
>  Components: Git, Mercurial, Subversion
> Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 
> 14:58:54+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: 
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
> Fix For: 2.4
>
> Attachments: add-tag-to-release-poms-1329108.patch, 
> add-tag-to-release-poms.patch
>
>
> With SVN the developerConnection and connection are
> updated to the "real" release URL, that is when I invoke release:prepare with
> a URL like:
> https://SVNSERVER/svn/REPO/myproject/branches/release it will be
> replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
> which is fine because now you know which revision to checkout for
> building the release.
> With git there is no such possibility to realize this with rewriting
> the URL AFAIK. So I would have expected however, that maybe the 
> //project/scm/tag
> element would be updated to reflect the fact, that the pom is the one
> of release, either to the "symbolic name" myproject-1.0 or to the hash
> of the tag.
> See http://markmail.org/thread/m77cvhqqq56krzzd as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MINDEXER-53) Typo: "updating indexes" should be "updating indices" or "updating index"

[MiB (JIRA)]

MiB created MINDEXER-53:
---

 Summary: Typo: "updating indexes" should be "updating indices" or 
"updating index"
 Key: MINDEXER-53
 URL: https://jira.codehaus.org/browse/MINDEXER-53
 Project: Maven Indexer
  Issue Type: Improvement
 Environment: Eclipse 3.7, Springsource Tool Suite 2.9, M2e 1.0 
Reporter: MiB
Priority: Trivial


When updating index central Eclipsebase Springsource Tool Suite 2.9 the plugin 
states it's "updating indexes" which I believe is a typo. Either it should be 
"updating indices" if several indices are being updated or "updating index" if 
it's just a one. 
I'm not sure where this string comes from, but Maven indexer felt the most 
appropriate. If it's the m2e JIRA I should direct this to, please kill it here 
and I'll post there instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-633) release:prepare on CVS flat multi-module project breaks at tagging

[slaurent (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297666#comment-297666
 ] 

slaurent commented on MRELEASE-633:
---

The problem is still present with version 2.2.1 :-( 
Is there a workaround ?

> release:prepare on CVS flat multi-module project breaks at tagging
> --
>
> Key: MRELEASE-633
> URL: https://jira.codehaus.org/browse/MRELEASE-633
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.1, 2.2
> Environment: - Maven 3.0.1
> - Tested with relase-plugin 2.1 and 2.2-SNAPSHOT
>Reporter: Michael Glauche
>
> When running "mvn release:prepare -DcommitByProject=true" on a simple flat 
> multi-module (parent and module are in the same directory) project the goal 
> does exit with:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on 
> project test-main: The scm url is invalid.
> [ERROR] - The connection string contains too few tokens.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) 
> on project test-main: The scm url is invalid.
>   - The connection string contains too few tokens.
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> 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:597)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoFailureException: The scm url is 
> invalid.
>   - The connection string contains too few tokens.
> at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
> at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
> ... 19 more
> Caused by: org.apache.maven.shared.release.scm.ReleaseScmRepositoryException: 
> The scm url is invalid.
>   - The connection string contains too few tokens.
> at 
> org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:87)
> at 
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
> at 
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
> at 
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
> at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
> ... 22 more
> However, the cvs commits earlier do work fine :
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -q commit -R -F 
> C:\Users\mglauche\AppData\Local\Temp\scm-commit-message1543133116513199803.txt
>  pom.xml"
> [INFO] Working directory: C:\work\workspaces\maven\test-main
> ...
> test-main pom.xml:
>  
>   
> scm:cvs:ps

[jira] (MSKINS-40) left column is too big since fluido 1.2

[Andreas Sewe (JIRA)]

[ 
https://jira.codehaus.org/browse/MSKINS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297669#comment-297669
 ] 

Andreas Sewe commented on MSKINS-40:


This might be a consequence of MSKINS-28. (FWIW, MSKINS-28 has been re-opened 
by me with a different patch, which doesn't use the CSS that may have triggered 
this issue.)

> left column is too big since fluido 1.2
> ---
>
> Key: MSKINS-40
> URL: https://jira.codehaus.org/browse/MSKINS-40
> Project: Maven Skins
>  Issue Type: Bug
>  Components: Fluido Skin
>Affects Versions: fluido-1.2, fluido-1.2.1
>Reporter: Herve Boutemy
>
> if you compare the rendered result from
> 1. fuido 1.1: http://maven.apache.org/skins/maven-fluido-skin-1.1/
> 2. and fluido 1.2: http://maven.apache.org/skins/maven-fluido-skin-1.2/
> the left column was well sized in 1.1 but has grown in 1.2 for non-obvious 
> reasons

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MCOMPILER-169) Jboss AS6.1 build with OpenJdk1.7 failure

[D T (JIRA)]

D T created MCOMPILER-169:
-

 Summary: Jboss AS6.1 build with OpenJdk1.7 failure
 Key: MCOMPILER-169
 URL: https://jira.codehaus.org/browse/MCOMPILER-169
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.3.2
 Environment: Ubuntu + Jboss AS6.1.0
Reporter: D T
 Attachments: log.txt

/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/metadata/test/AbstractMetaDataTest.java:[88,38]
 error: name clash: getDelegate(Class) in AbstractMetaDataTest and 
getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
hides the other
[ERROR] 
/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/integration/test/AbstractJMXAnnotationTest.java:[65,38]
 error: name clash: getDelegate(Class) in AbstractJMXAnnotationTest and 
getDelegate(Class) in AbstractIntegrationTest have the same erasure, yet 
neither hides the other
[ERROR] 
/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/parse/test/ErrorInParseOldUnitTestCase.java:[47,38]
 error: name clash: getDelegate(Class) in ErrorInParseOldUnitTestCase and 
getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
hides the other
[ERROR] 
/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/value/text/test/TextValueOldUnitTestCase.java:[48,38]
 error: name clash: getDelegate(Class) in TextValueOldUnitTestCase and 
getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
hides the other
[ERROR] 
/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/attribute/test/DependsListAttributeNewUnitTestCase.java:[46,38]
 error: name clash: getDelegate(Class) in 
DependsListAttributeNewUnitTestCase and getDelegate(Class) in 
AbstractSystemTest have the same erasure, yet neither hides the other
[ERROR] 
/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/attribute/test/AttributeOldUnitTestCase.java:[48,38]
 error: name clash: getDelegate(Class) in AttributeOldUnitTestCase and 
getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
hides the other
[ERROR] 
/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/basic/test/DoubleInstallOldUnitTestCase.java:[48,38]
 error: name clash: getDelegate(Class) in DoubleInstallOldUnitTestCase and 
getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
hides the other
[ERROR] 
/home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/attribute/test/DependsListAttributeOldUnitTestCase.java:[50,38]
 error: name clash: getDelegate(Class) in 
DependsListAttributeOldUnitTestCase and getDelegate(Class) in 
AbstractSystemTest have the same erasure, yet neither hides the other

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJARSIGNER-24) Use Password Encryption in pom.xml

[Zang MingJie (JIRA)]

Zang MingJie created MJARSIGNER-24:
--

 Summary: Use Password Encryption in pom.xml
 Key: MJARSIGNER-24
 URL: https://jira.codehaus.org/browse/MJARSIGNER-24
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: New Feature
Reporter: Zang MingJie
 Attachments: patch

See http://maven.apache.org/guides/mini/guide-encryption.html

Here is a patch for it

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.

[Mark Struberg (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297670#comment-297670
 ] 

Mark Struberg commented on MRELEASE-723:


I've now reviewed the patch and think we need to think a bit harder about this 
;)

a.) The ScmTranslator was a perfect starting point, but I think it's not yet 
full cycle.

You added the code:
public String resolveTag( String tag )
{
if ( !"HEAD".equals( tag ) )
{
return tag;
}
else
{
return null;
}
}

but there is no special 'HEAD' tag in GIT nor hg. I assume you've copied that 
over from the CvsScmTranslator, right? So this doesn't suite for GIT and we 
should just return tag instead.


I like to try another route:
Currently we had to add a new ScmTranslator for all new SCMs, but that doesn't 
scale. 
I've now created a new DefaultScmTranslator which will get created if NO other 
(special) ScmTranslator gets picked up. This one just returns the unchanged 
URLs and the tag. 

The main change is that we now _allways_ rewrite the pom and set the tag!


PS:I've kept your unit tests (but didn't yet fix the code style).
PPS: We need to review the HEAD stuff in the other ScmTranslators as well (e.g. 
ClearCase).
PPPS: will upload the patch after fixing the tests

> DCVS tagging commands should store the tag-name (or hash) in the the 
> //project/scm/tag element.
> ---
>
> Key: MRELEASE-723
> URL: https://jira.codehaus.org/browse/MRELEASE-723
> Project: Maven 2.x Release Plugin
>  Issue Type: New Feature
>  Components: Git, Mercurial, Subversion
> Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 
> 14:58:54+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: 
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Mark Struberg
> Fix For: 2.4
>
> Attachments: add-tag-to-release-poms-1329108.patch, 
> add-tag-to-release-poms.patch
>
>
> With SVN the developerConnection and connection are
> updated to the "real" release URL, that is when I invoke release:prepare with
> a URL like:
> https://SVNSERVER/svn/REPO/myproject/branches/release it will be
> replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
> which is fine because now you know which revision to checkout for
> building the release.
> With git there is no such possibility to realize this with rewriting
> the URL AFAIK. So I would have expected however, that maybe the 
> //project/scm/tag
> element would be updated to reflect the fact, that the pom is the one
> of release, either to the "symbolic name" myproject-1.0 or to the hash
> of the tag.
> See http://markmail.org/thread/m77cvhqqq56krzzd as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.

[Mark Struberg (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg updated MRELEASE-723:
---

Attachment: MRELEASE-723-idea.patch

basic approach without unit tests yet.

> DCVS tagging commands should store the tag-name (or hash) in the the 
> //project/scm/tag element.
> ---
>
> Key: MRELEASE-723
> URL: https://jira.codehaus.org/browse/MRELEASE-723
> Project: Maven 2.x Release Plugin
>  Issue Type: New Feature
>  Components: Git, Mercurial, Subversion
> Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 
> 14:58:54+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: 
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Mark Struberg
> Fix For: 2.4
>
> Attachments: add-tag-to-release-poms-1329108.patch, 
> add-tag-to-release-poms.patch, MRELEASE-723-idea.patch
>
>
> With SVN the developerConnection and connection are
> updated to the "real" release URL, that is when I invoke release:prepare with
> a URL like:
> https://SVNSERVER/svn/REPO/myproject/branches/release it will be
> replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
> which is fine because now you know which revision to checkout for
> building the release.
> With git there is no such possibility to realize this with rewriting
> the URL AFAIK. So I would have expected however, that maybe the 
> //project/scm/tag
> element would be updated to reflect the fact, that the pom is the one
> of release, either to the "symbolic name" myproject-1.0 or to the hash
> of the tag.
> See http://markmail.org/thread/m77cvhqqq56krzzd as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJAR-154) Clean apache-snapshots repo from IT settings.xml

[Anders Hammar (JIRA)]

Anders Hammar created MJAR-154:
--

 Summary: Clean apache-snapshots repo from IT settings.xml
 Key: MJAR-154
 URL: https://jira.codehaus.org/browse/MJAR-154
 Project: Maven 2.x JAR Plugin
  Issue Type: Task
 Environment: n/a
Reporter: Anders Hammar
Priority: Minor


In src/it/settings.xml I found the following comment:

{code}


  apache.snapshots
  
https://repository.apache.org/content/groups/snapshots-group/
  
false
  
  
true
  

{code}

maven-archiver v2.5 has been released and the dependency of the plugin is 
already updated. I haven't tested, but I assume this can now be cleaned up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MINDEXER-52) reentrant locking in DefaultIndexingContent flawed

[Jesse Glick (JIRA)]

[ 
https://jira.codehaus.org/browse/MINDEXER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297698#comment-297698
 ] 

Jesse Glick commented on MINDEXER-52:
-

Assuming the "bottle warmer" is intended to preload Lucene indices for quick 
response times, this seems quite inappropriate to be called by default by a 
library like Maven Indexer, and probably should not even be present there in 
code. While it makes sense for a server like Nexus, which can take its time 
starting up but needs to be responsive thereafter, it makes no sense for a CLI 
utility embedding the library which only needs to do a handful of operations 
and then exit; nor does it make sense for embedding in a desktop app like an 
IDE, which may well perform warmup operations but likely has its own carefully 
tuned schedule for doing so (and likely cannot afford to waste a native thread 
sitting on each Maven repository).

> reentrant locking in DefaultIndexingContent flawed
> --
>
> Key: MINDEXER-52
> URL: https://jira.codehaus.org/browse/MINDEXER-52
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Milos Kleint
>Priority: Critical
>
> DefaultIndexingContent.java contains the following pattern:
> {code:java}
> public IndexReader getIndexReader()
> throws IOException
> {
> lock();
> try
> {
> return indexReader;
> }
> finally
> {
> unlock();
> }
> }
> {code}
> together with installBottleWarmer() method that spawns a concurrent thread 
> that performs "warmup" operations, it makes it impossible to access the 
> indexReader instance safely. A correct approach would be to wrap the entire 
> operation with the indexreader in the mutex lock, not the the accessor method.
> please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706  and 
> http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples 
> when this approach is failing. it's fairly rare but  keeps on reoccuring, all 
> access (searching, indexing) from netbeans is protected by a mutex and 
> happens exclusively. I'm assuming that the installBottleWarmer() thread is 
> the one iterfering with our access occasionally.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MCOMPILER-169) Jboss AS6.1 build with OpenJdk1.7 failure

[Joerg Schaible (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297699#comment-297699
 ] 

Joerg Schaible commented on MCOMPILER-169:
--

Why do you think that the plugin solves someone else's coding errors? Simply 
call mvn with "-X" option and have a look at the executed command line. If you 
call this line manually, you will get the same errors - no Maven involved.

> Jboss AS6.1 build with OpenJdk1.7 failure
> -
>
> Key: MCOMPILER-169
> URL: https://jira.codehaus.org/browse/MCOMPILER-169
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 2.3.2
> Environment: Ubuntu + Jboss AS6.1.0
>Reporter: D T
> Attachments: log.txt
>
>
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/metadata/test/AbstractMetaDataTest.java:[88,38]
>  error: name clash: getDelegate(Class) in AbstractMetaDataTest and 
> getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
> hides the other
> [ERROR] 
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/integration/test/AbstractJMXAnnotationTest.java:[65,38]
>  error: name clash: getDelegate(Class) in AbstractJMXAnnotationTest and 
> getDelegate(Class) in AbstractIntegrationTest have the same erasure, yet 
> neither hides the other
> [ERROR] 
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/parse/test/ErrorInParseOldUnitTestCase.java:[47,38]
>  error: name clash: getDelegate(Class) in ErrorInParseOldUnitTestCase and 
> getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
> hides the other
> [ERROR] 
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/value/text/test/TextValueOldUnitTestCase.java:[48,38]
>  error: name clash: getDelegate(Class) in TextValueOldUnitTestCase and 
> getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
> hides the other
> [ERROR] 
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/attribute/test/DependsListAttributeNewUnitTestCase.java:[46,38]
>  error: name clash: getDelegate(Class) in 
> DependsListAttributeNewUnitTestCase and getDelegate(Class) in 
> AbstractSystemTest have the same erasure, yet neither hides the other
> [ERROR] 
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/attribute/test/AttributeOldUnitTestCase.java:[48,38]
>  error: name clash: getDelegate(Class) in AttributeOldUnitTestCase and 
> getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
> hides the other
> [ERROR] 
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/basic/test/DoubleInstallOldUnitTestCase.java:[48,38]
>  error: name clash: getDelegate(Class) in DoubleInstallOldUnitTestCase and 
> getDelegate(Class) in AbstractSystemTest have the same erasure, yet neither 
> hides the other
> [ERROR] 
> /home/dtsybin/git/kszkipo-server-jboss6/system-jmx/src/test/java/org/jboss/test/system/controller/configure/attribute/test/DependsListAttributeOldUnitTestCase.java:[50,38]
>  error: name clash: getDelegate(Class) in 
> DependsListAttributeOldUnitTestCase and getDelegate(Class) in 
> AbstractSystemTest have the same erasure, yet neither hides the other

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5280) Inconsistent order of repositories and pluginRepositories from profiles in settings (regression Maven 3)

[Anders Hammar (JIRA)]

Anders Hammar created MNG-5280:
--

 Summary: Inconsistent order of repositories and pluginRepositories 
from profiles in settings (regression Maven 3)
 Key: MNG-5280
 URL: https://jira.codehaus.org/browse/MNG-5280
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Settings
Affects Versions: 3.0.4, 3.0.3
 Environment: Mac OS 10.7 and Windows XP
Java 1.6.0
Reporter: Anders Hammar


Repositories and pluginRepositories defined in profiles in settings.xml are not 
order consistently. This is a regression compared to Maven 2.

Scenario:
* Settings.xml defines two profiles, A and B (in this order).
* Both profiles define a repository and a pluginRepository, A-repo/A-pluginrepo 
and B-repo/B-pluginrepo respectively.

When checking the effective pom (help:effective-pom) the resulting list of 
repositories and pluginRepositories shows that they are not ordered 
consistently. The order is B-repo, A-repo and A-pluginrepo, B-pluginrepo 
respectively. With Maven 2.2.1 they are ordered consistently (and what I argue 
is correct): B-repo, A-repo and B-pluginrepo, A-pluginrepo.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-633) release:prepare on CVS flat multi-module project breaks at tagging

[Robert Scholte (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRELEASE-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MRELEASE-633:


Description: 
When running "{{mvn release:prepare -DcommitByProject=true}}" on a simple flat 
multi-module (parent and module are in the same directory) project the goal 
does exit with:
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on 
project test-main: The scm url is invalid.
[ERROR] - The connection string contains too few tokens.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on 
project test-main: The scm url is invalid.
  - The connection string contains too few tokens.
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
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:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureException: The scm url is invalid.
  - The connection string contains too few tokens.
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
... 19 more
Caused by: org.apache.maven.shared.release.scm.ReleaseScmRepositoryException: 
The scm url is invalid.
  - The connection string contains too few tokens.
at 
org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:87)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
... 22 more
{noformat}
However, the cvs commits earlier do work fine :
{noformat}
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "cvs -z3 -f -q commit -R -F 
C:\Users\mglauche\AppData\Local\Temp\scm-commit-message1543133116513199803.txt 
pom.xml"
[INFO] Working directory: C:\work\workspaces\maven\test-main
...
{noformat}

test-main {{pom.xml}}:
{code:xml}
 
  
scm:cvs:pserver:${maven.scm.username}@cvsserver:/home/cvs/repository/test:test-main
  
   
../module1
  
{code}
module1 {{pom.xml}}:
{code:xml}
  
test-main
somegroup
0.0.2-SNAPSHOT
../test-main
  
  somegroup
  module1
  0.0.2-SNAPSHOT
   

scm:cvs:pserver:${maven.scm.username}@cvsserver:/home/cvs/repository/test:module1
   
{code}

${maven.scm.username} is set to the correct user with a {{settings.xml}} 
parameter.

The interesting thing is, the SCM provider does think the pom is valid:
{noformat}
$ mvn scm:validate
[INFO] --- maven-scm-plugin:1.4:validate (default-cli) @ test-main ---
[INFO] connectionUrl scm connection string is valid.
[INFO] project.scm.connection scm connection string is valid.
{n

[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.

[Robert Scholte (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297732#comment-297732
 ] 

Robert Scholte commented on MRELEASE-723:
-

Mirko, just to clearify myself a bit: it looks to me that the {{String 
translateTagUrl( String url, String tag, String tagBase )}} is the one which 
should be implemented instead of the {{String resolveTag( String tag )}}

> DCVS tagging commands should store the tag-name (or hash) in the the 
> //project/scm/tag element.
> ---
>
> Key: MRELEASE-723
> URL: https://jira.codehaus.org/browse/MRELEASE-723
> Project: Maven 2.x Release Plugin
>  Issue Type: New Feature
>  Components: Git, Mercurial, Subversion
> Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 
> 14:58:54+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: 
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Mark Struberg
> Fix For: 2.4
>
> Attachments: add-tag-to-release-poms-1329108.patch, 
> add-tag-to-release-poms.patch, MRELEASE-723-idea.patch
>
>
> With SVN the developerConnection and connection are
> updated to the "real" release URL, that is when I invoke release:prepare with
> a URL like:
> https://SVNSERVER/svn/REPO/myproject/branches/release it will be
> replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
> which is fine because now you know which revision to checkout for
> building the release.
> With git there is no such possibility to realize this with rewriting
> the URL AFAIK. So I would have expected however, that maybe the 
> //project/scm/tag
> element would be updated to reflect the fact, that the pom is the one
> of release, either to the "symbolic name" myproject-1.0 or to the hash
> of the tag.
> See http://markmail.org/thread/m77cvhqqq56krzzd as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5204) Invalid shell bounce call command

[Jeff Molsen (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297734#comment-297734
 ] 

Jeff Molsen commented on MNG-5204:
--

Similarly, on SunOS (5.10 Generic_147441-09 i86pc i386 i86pc) I get the same 
error.
However, I found a work around which might offer some insight to the issue, and 
possibly help with testing a solution.

The following failed with the same error reported above:
/bin/sh -c ls -1nlad 
/opt/bamboo/bamboo4.0/xml-data/build-dir/ABCWEB-ABCWEBDEV-PUBLISHJOB/abc-web/abc-web-ui/pom.xml

The following (with a shorter path) worked fine:
/bin/sh -c ls -1nlad 
/opt/bamboo/bamboo4.0/xml-data/build-dir/ABCWEB-ABCWEBDEV-JOB1/abc-web/abc-web-ui/pom.xml

I'm using Maven through Bamboo which generates build directories based on build 
plan (and job) names.  When I redefined my job name to be shorter, it worked 
fine.  I figured this out because other builds I had for the same code that 
were being deployed to different hosts (and had different, and shorter, job 
names) were working fine.  So, renaming the job to a name of similar length to 
the jobs that were working solved the issue.

> Invalid shell bounce call command
> -
>
> Key: MNG-5204
> URL: https://jira.codehaus.org/browse/MNG-5204
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.0.3
> Environment: Mac OS X Lion, Intellij IDEA 10.x version
>Reporter: Alexey Korchevsky
>Priority: Blocker
>
> I create simple hello world project, and run build it by maven.
> Maven run command "jar:jar", and it use org.codehaus.plexus-io component. 
> This component throws exception:
> {code}
> Caused by: java.io.IOException: Failed to retrieve numeric file attributes 
> using: '/bin/sh -c ls -1nlad /Users/mitallast/Sites/test/pom.xml'
>   at 
> org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.executeLs(PlexusIoResourceAttributeUtils.java:281)
>   at 
> org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributesByPath(PlexusIoResourceAttributeUtils.java:223)
>   at 
> org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributes(PlexusIoResourceAttributeUtils.java:168)
>   at 
> org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:157)
>   ... 32 more
> {code}
> Note, generated shell command is invalid:
> {code}/bin/sh -c ls -1nlad /Users/mitallast/Sites/test/pom.xml{code}
> Correct command like as 
> {code}/bin/sh -c "ls -1nlad /Users/mitallast/Sites/test/pom.xml"{code}
> Shell option "-c" is short equivalent of "command". Value for this option is 
> a shell command string. Plexus component didn't escape and not add quotes to 
> generated "ls" command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJAR-154) Clean apache-snapshots repo from IT settings.xml

[Olivier Lamy (JIRA)]

 [ 
https://jira.codehaus.org/browse/MJAR-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MJAR-154.
-

Resolution: Fixed

fixed r1333166

> Clean apache-snapshots repo from IT settings.xml
> 
>
> Key: MJAR-154
> URL: https://jira.codehaus.org/browse/MJAR-154
> Project: Maven 2.x JAR Plugin
>  Issue Type: Task
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Olivier Lamy
>Priority: Minor
>
> In src/it/settings.xml I found the following comment:
> {code}
> 
> 
>   apache.snapshots
>   
> https://repository.apache.org/content/groups/snapshots-group/
>   
> false
>   
>   
> true
>   
> 
> {code}
> maven-archiver v2.5 has been released and the dependency of the plugin is 
> already updated. I haven't tested, but I assume this can now be cleaned up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.

[Mirko Friedenhagen (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297743#comment-297743
 ] 

Mirko Friedenhagen commented on MRELEASE-723:
-

Robert, thanks for the clarification. 

I had a look into Mark's patch and to me it looks like Mark is on the right 
trail by implementing a DefaultScmTranslator which does not fiddle around at 
all with given tags or urls and is IMHO appropriate out of the box at least for 
Bazaar, Mercurial and Git (and probably even for CVS, as I do not think anyone 
will "release" a version called HEAD anyway). The only SCM I know of which 
fiddles around with urls and tags and branches is Subversion.

So what's next? Mark, will you take care of this issue from now on? When I 
could be of help nonetheless we should find a way to share work, thought 
without a DCVS this will be harder :-).

Regards
Mirko

> DCVS tagging commands should store the tag-name (or hash) in the the 
> //project/scm/tag element.
> ---
>
> Key: MRELEASE-723
> URL: https://jira.codehaus.org/browse/MRELEASE-723
> Project: Maven 2.x Release Plugin
>  Issue Type: New Feature
>  Components: Git, Mercurial, Subversion
> Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 
> 14:58:54+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: 
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Mark Struberg
> Fix For: 2.4
>
> Attachments: add-tag-to-release-poms-1329108.patch, 
> add-tag-to-release-poms.patch, MRELEASE-723-idea.patch
>
>
> With SVN the developerConnection and connection are
> updated to the "real" release URL, that is when I invoke release:prepare with
> a URL like:
> https://SVNSERVER/svn/REPO/myproject/branches/release it will be
> replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
> which is fine because now you know which revision to checkout for
> building the release.
> With git there is no such possibility to realize this with rewriting
> the URL AFAIK. So I would have expected however, that maybe the 
> //project/scm/tag
> element would be updated to reflect the fact, that the pom is the one
> of release, either to the "symbolic name" myproject-1.0 or to the hash
> of the tag.
> See http://markmail.org/thread/m77cvhqqq56krzzd as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SCM-452) scm url not being parsed correctly for release:perform only

[Robert Scholte (JIRA)]

 [ 
https://jira.codehaus.org/browse/SCM-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated SCM-452:
---

Description: 
{{mvn release:perform 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname}}
works, except it won't really do what we need without a lot of manual 
intervention, because this command:
{{mvn release:prepare 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname
 }}
yields this error:
{noformat}
[ERROR] BUILD FAILURE
[INFO] 
[INFO] The scm url is invalid.
  - The connection string contains too few tokens.
[INFO] 
{noformat}

{{-e}} doesn't reveal a long enough stack trace to show anything.  It would be 
helpful if this error could say what url it's parsing
the scm section of the pom is this:
{code:xml}


scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot:projectname

{code}
We don't intend to put the user name in the pom (shared resource) which is part 
of why I'm trying to override it.

and the servers section of {{settings.xml}} is like so:
{code:xml}

  cvs-server.mycompany.com
  664
  775
  username
  /home/username/.ssh/id_rsa_of_this_setup

{code}

but in any case I'm not sure it's even reading the scm section of the pom 
correctly.  After downloading the plugin sources, one of the few unresolved 
items was the {{Xpp3Reader}} which might have told me the answer.  This is not 
up to my experience of a high bar set by working with this plugin in a 
subversion environment, but maybe it's an unfair comparison.

Any attention greatly appreciated

--Ben Clark

  was:
mvn release:perform 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname
works, except it won't really do what we need without a lot of manual 
intervention, because this command:
mvn release:prepare 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname
 
yields this error:
[ERROR] BUILD FAILURE
[INFO] 
[INFO] The scm url is invalid.
  - The connection string contains too few tokens.
[INFO] 

-e doesn't reveal a long enough stack trace to show anything.  It would be 
helpful if this error could say what url it's parsing
the scm section of the pom is this:


scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot:projectname


We don't intend to put the user name in the pom (shared resource) which is part 
of why I'm trying to override it.

and the servers section of settings.xml is like so:

  cvs-server.mycompany.com
  664
  775
  username
  /home/username/.ssh/id_rsa_of_this_setup



but in any case I'm not sure it's even reading the scm section of the pom 
correctly.  After downloading the plugin sources, one of the few unresolved 
items was the Xpp3Reader which might have told me the answer.  This is not up 
to my experience of a high bar set by working with this plugin in a subversion 
environment, but maybe it's an unfair comparison.

Any attention greatly appreciated

--Ben Clark


> scm url not being parsed correctly for release:perform only
> ---
>
> Key: SCM-452
> URL: https://jira.codehaus.org/browse/SCM-452
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 2.0
> Environment: reproduced on Windows Vista ultimate 32bit, w/ Sun jdk 
> 1.5.0_17, ubuntu 2.6.27-11-generic, with openjdk 1.6 (result of apt-get 
> install maven2).  Also happens in a windows eclipse workspace w/ m2eclipse, 
> project checked out as maven project with from a repository location defined 
> with ext protocol (not extssh)
>Reporter: Ben Clark
>
> {{mvn release:perform 
> -DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname}}
> works, except it won't really do what we need without a lot of manual 
> intervention, because this command:
> {{mvn release:prepare 
> -DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname
>  }}
> yields this error:
> {noformat}
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] The scm url is invalid.
>   - The connection string co

[jira] (SCM-452) scm url not being parsed correctly for release:perform only

[Robert Scholte (JIRA)]

 [ 
https://jira.codehaus.org/browse/SCM-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated SCM-452:
---

Description: 
{{mvn release:perform 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname}}
works, except it won't really do what we need without a lot of manual 
intervention, because this command:
{{mvn release:prepare 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname}}
yields this error:
{noformat}
[ERROR] BUILD FAILURE
[INFO] 
[INFO] The scm url is invalid.
  - The connection string contains too few tokens.
[INFO] 
{noformat}

{{-e}} doesn't reveal a long enough stack trace to show anything.  It would be 
helpful if this error could say what url it's parsing
the scm section of the pom is this:
{code:xml}


scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot:projectname

{code}
We don't intend to put the user name in the pom (shared resource) which is part 
of why I'm trying to override it.

and the servers section of {{settings.xml}} is like so:
{code:xml}

  cvs-server.mycompany.com
  664
  775
  username
  /home/username/.ssh/id_rsa_of_this_setup

{code}

but in any case I'm not sure it's even reading the scm section of the pom 
correctly.  After downloading the plugin sources, one of the few unresolved 
items was the {{Xpp3Reader}} which might have told me the answer.  This is not 
up to my experience of a high bar set by working with this plugin in a 
subversion environment, but maybe it's an unfair comparison.

Any attention greatly appreciated

--Ben Clark

  was:
{{mvn release:perform 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname}}
works, except it won't really do what we need without a lot of manual 
intervention, because this command:
{{mvn release:prepare 
-DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname
 }}
yields this error:
{noformat}
[ERROR] BUILD FAILURE
[INFO] 
[INFO] The scm url is invalid.
  - The connection string contains too few tokens.
[INFO] 
{noformat}

{{-e}} doesn't reveal a long enough stack trace to show anything.  It would be 
helpful if this error could say what url it's parsing
the scm section of the pom is this:
{code:xml}


scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot

scm:cvs:ext:cvs-server.mycompany.com:/cvsroot:projectname

{code}
We don't intend to put the user name in the pom (shared resource) which is part 
of why I'm trying to override it.

and the servers section of {{settings.xml}} is like so:
{code:xml}

  cvs-server.mycompany.com
  664
  775
  username
  /home/username/.ssh/id_rsa_of_this_setup

{code}

but in any case I'm not sure it's even reading the scm section of the pom 
correctly.  After downloading the plugin sources, one of the few unresolved 
items was the {{Xpp3Reader}} which might have told me the answer.  This is not 
up to my experience of a high bar set by working with this plugin in a 
subversion environment, but maybe it's an unfair comparison.

Any attention greatly appreciated

--Ben Clark


> scm url not being parsed correctly for release:perform only
> ---
>
> Key: SCM-452
> URL: https://jira.codehaus.org/browse/SCM-452
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 2.0
> Environment: reproduced on Windows Vista ultimate 32bit, w/ Sun jdk 
> 1.5.0_17, ubuntu 2.6.27-11-generic, with openjdk 1.6 (result of apt-get 
> install maven2).  Also happens in a windows eclipse workspace w/ m2eclipse, 
> project checked out as maven project with from a repository location defined 
> with ext protocol (not extssh)
>Reporter: Ben Clark
>
> {{mvn release:perform 
> -DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname}}
> works, except it won't really do what we need without a lot of manual 
> intervention, because this command:
> {{mvn release:prepare 
> -DconnectionUrl=scm:cvs:ext:usern...@cvs-server.mycompany.com:/cvsroot:projectname}}
> yields this error:
> {noformat}
> [ERROR] BUILD FAILURE
> [INFO] 
> --

[jira] (MNG-5204) Invalid shell bounce call command

[Jeff Molsen (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297734#comment-297734
 ] 

Jeff Molsen edited comment on MNG-5204 at 5/2/12 5:10 PM:
--

Similarly, on SunOS (5.10 Generic_147441-09 i86pc i386 i86pc) I get what 
appears to be the same error.
However, I found a work around which might offer some insight to the issue, and 
possibly help with testing a solution.

The error I get:
Failed to retrieve numeric file attributes using: '/bin/sh -c ls -1nlad 
/opt/bamboo/bamboo4.0/xml-data/build-dir/path/to/pom.xml': Error while 
executing process. Cannot run program "/bin/sh": error=12, Not enough space

I'm using Maven through Bamboo which generates build directories based on build 
plan (and job) names.  When I deleted everything under build-dir, and re-ran 
the build succeeded.  I'm not sure why it's reporting "Not enough space" as df 
reports plenty of space on the partition.

  was (Author: jmolsen):
Similarly, on SunOS (5.10 Generic_147441-09 i86pc i386 i86pc) I get the 
same error.
However, I found a work around which might offer some insight to the issue, and 
possibly help with testing a solution.

The following failed with the same error reported above:
/bin/sh -c ls -1nlad 
/opt/bamboo/bamboo4.0/xml-data/build-dir/ABCWEB-ABCWEBDEV-PUBLISHJOB/abc-web/abc-web-ui/pom.xml

The following (with a shorter path) worked fine:
/bin/sh -c ls -1nlad 
/opt/bamboo/bamboo4.0/xml-data/build-dir/ABCWEB-ABCWEBDEV-JOB1/abc-web/abc-web-ui/pom.xml

I'm using Maven through Bamboo which generates build directories based on build 
plan (and job) names.  When I redefined my job name to be shorter, it worked 
fine.  I figured this out because other builds I had for the same code that 
were being deployed to different hosts (and had different, and shorter, job 
names) were working fine.  So, renaming the job to a name of similar length to 
the jobs that were working solved the issue.
  
> Invalid shell bounce call command
> -
>
> Key: MNG-5204
> URL: https://jira.codehaus.org/browse/MNG-5204
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.0.3
> Environment: Mac OS X Lion, Intellij IDEA 10.x version
>Reporter: Alexey Korchevsky
>Priority: Blocker
>
> I create simple hello world project, and run build it by maven.
> Maven run command "jar:jar", and it use org.codehaus.plexus-io component. 
> This component throws exception:
> {code}
> Caused by: java.io.IOException: Failed to retrieve numeric file attributes 
> using: '/bin/sh -c ls -1nlad /Users/mitallast/Sites/test/pom.xml'
>   at 
> org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.executeLs(PlexusIoResourceAttributeUtils.java:281)
>   at 
> org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributesByPath(PlexusIoResourceAttributeUtils.java:223)
>   at 
> org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributes(PlexusIoResourceAttributeUtils.java:168)
>   at 
> org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:157)
>   ... 32 more
> {code}
> Note, generated shell command is invalid:
> {code}/bin/sh -c ls -1nlad /Users/mitallast/Sites/test/pom.xml{code}
> Correct command like as 
> {code}/bin/sh -c "ls -1nlad /Users/mitallast/Sites/test/pom.xml"{code}
> Shell option "-c" is short equivalent of "command". Value for this option is 
> a shell command string. Plexus component didn't escape and not add quotes to 
> generated "ls" command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MCHANGES-281) jira report fails with Jira 5.0.3 (NPE)

[Swapnil Sapar (JIRA)]

Swapnil Sapar created MCHANGES-281:
--

 Summary: jira report fails with Jira 5.0.3 (NPE)
 Key: MCHANGES-281
 URL: https://jira.codehaus.org/browse/MCHANGES-281
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: jira
Affects Versions: 2.6
 Environment: OS: Mac
Maven: 3.0.4
Java: 1.6
Jira: 5.0.3
maven-changes-plugin: 2.6
Reporter: Swapnil Sapar


Cannot generate jira-report or announcement-mail using Jira 5.0.3. These goals 
worked perfectly with Jira 4.X

{code}
[INFO] --- maven-changes-plugin:2.6:announcement-generate (default-cli) @ 
hello-world ---
May 2, 2012 4:16:55 PM org.apache.commons.httpclient.HttpMethodBase 
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using 
getResponseBodyAsStream instead is recommended.
May 2, 2012 4:16:56 PM org.apache.commons.httpclient.HttpMethodBase 
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using 
getResponseBodyAsStream instead is recommended.
[ERROR] Error accessing http://jira.xy.z/jira/browse/ABC
java.lang.NullPointerException
at 
org.apache.maven.plugin.jira.JiraHelper.getPidFromJira(JiraHelper.java:142)
at 
org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:389)
at 
org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:723)
at 
org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:488)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[WARNING] JIRA file codebase/target/jira-announcement.xml doesn't exist.

{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MCHANGES-281) jira report fails with Jira 5.0.3 (NPE)

[Swapnil Sapar (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCHANGES-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Swapnil Sapar updated MCHANGES-281:
---

Attachment: MCHANGES-281-fix.patch

Attached patch with a simple fix for Jira 5

> jira report fails with Jira 5.0.3 (NPE)
> ---
>
> Key: MCHANGES-281
> URL: https://jira.codehaus.org/browse/MCHANGES-281
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira
>Affects Versions: 2.6
> Environment: OS: Mac
> Maven: 3.0.4
> Java: 1.6
> Jira: 5.0.3
> maven-changes-plugin: 2.6
>Reporter: Swapnil Sapar
> Attachments: MCHANGES-281-fix.patch
>
>
> Cannot generate jira-report or announcement-mail using Jira 5.0.3. These 
> goals worked perfectly with Jira 4.X
> {code}
> [INFO] --- maven-changes-plugin:2.6:announcement-generate (default-cli) @ 
> hello-world ---
> May 2, 2012 4:16:55 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> May 2, 2012 4:16:56 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> [ERROR] Error accessing http://jira.xy.z/jira/browse/ABC
> java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.jira.JiraHelper.getPidFromJira(JiraHelper.java:142)
>   at 
> org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:389)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:723)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:488)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   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:597)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> [WARNING] JIRA file codebase/target/jira-announcement.xml doesn't exist.
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MCHANGES-281) jira report fails with Jira 5.0.3 (NPE)

[Swapnil Sapar (JIRA)]

[ 
https://jira.codehaus.org/browse/MCHANGES-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297753#comment-297753
 ] 

Swapnil Sapar edited comment on MCHANGES-281 at 5/3/12 1:29 AM:


Attached patch with a simple fix for Jira 5.
-

Jira 5.0.1 has additional instances of *{{data-pid="12345"}}* format which 
causes key to be null when parsing projectPage. Adding ? before search pattern 
?pid= fixes the issue by finding the required pattern *{{?pid=12345&}}*
Also Verified with older version of Jira 4.X

Jira 5 projectPage is as below...
{code}

  Task

{code}


  was (Author: swapsapar):
Attached patch with a simple fix for Jira 5.
-

Jira 5.0.1 has additional instances of {{data-pid="12345"}} format which causes 
key to be null when parsing projectPage. Adding ? before search pattern ?pid= 
fixes the issue by finding the required pattern {{?pid=12345&}}
Also Verified with older version of Jira 4.X

Jira 5 projectPage is as below...
{code}

  Task

{code}

  
> jira report fails with Jira 5.0.3 (NPE)
> ---
>
> Key: MCHANGES-281
> URL: https://jira.codehaus.org/browse/MCHANGES-281
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira
>Affects Versions: 2.6
> Environment: OS: Mac
> Maven: 3.0.4
> Java: 1.6
> Jira: 5.0.3
> maven-changes-plugin: 2.6
>Reporter: Swapnil Sapar
> Attachments: MCHANGES-281-fix.patch
>
>
> Cannot generate jira-report or announcement-mail using Jira 5.0.3. These 
> goals worked perfectly with Jira 4.X
> {code}
> [INFO] --- maven-changes-plugin:2.6:announcement-generate (default-cli) @ 
> hello-world ---
> May 2, 2012 4:16:55 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> May 2, 2012 4:16:56 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> [ERROR] Error accessing http://jira.xy.z/jira/browse/ABC
> java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.jira.JiraHelper.getPidFromJira(JiraHelper.java:142)
>   at 
> org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:389)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:723)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:488)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   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:597)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> [WARNING] JIRA file codebase/target/jira-announcement.xml doesn't exist.
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehau

[jira] (MCHANGES-281) jira report fails with Jira 5.0.3 (NPE)

[Swapnil Sapar (JIRA)]

[ 
https://jira.codehaus.org/browse/MCHANGES-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297753#comment-297753
 ] 

Swapnil Sapar edited comment on MCHANGES-281 at 5/3/12 1:28 AM:


Attached patch with a simple fix for Jira 5.
-

Jira 5.0.1 has additional instances of data-pid="12345" format which causes key 
to be null when parsing projectPage. Adding ? before search pattern ?pid= fixes 
the issue by finding the required pattern ?pid=12345&
Also Verified with older version of Jira 4.X

Jira 5 projectPage is as below...
{code}

  Task

{code}


  was (Author: swapsapar):
Attached patch with a simple fix for Jira 5
  
> jira report fails with Jira 5.0.3 (NPE)
> ---
>
> Key: MCHANGES-281
> URL: https://jira.codehaus.org/browse/MCHANGES-281
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira
>Affects Versions: 2.6
> Environment: OS: Mac
> Maven: 3.0.4
> Java: 1.6
> Jira: 5.0.3
> maven-changes-plugin: 2.6
>Reporter: Swapnil Sapar
> Attachments: MCHANGES-281-fix.patch
>
>
> Cannot generate jira-report or announcement-mail using Jira 5.0.3. These 
> goals worked perfectly with Jira 4.X
> {code}
> [INFO] --- maven-changes-plugin:2.6:announcement-generate (default-cli) @ 
> hello-world ---
> May 2, 2012 4:16:55 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> May 2, 2012 4:16:56 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> [ERROR] Error accessing http://jira.xy.z/jira/browse/ABC
> java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.jira.JiraHelper.getPidFromJira(JiraHelper.java:142)
>   at 
> org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:389)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:723)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:488)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   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:597)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> [WARNING] JIRA file codebase/target/jira-announcement.xml doesn't exist.
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MCHANGES-281) jira report fails with Jira 5.0.3 (NPE)

[Swapnil Sapar (JIRA)]

[ 
https://jira.codehaus.org/browse/MCHANGES-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297753#comment-297753
 ] 

Swapnil Sapar edited comment on MCHANGES-281 at 5/3/12 1:28 AM:


Attached patch with a simple fix for Jira 5.
-

Jira 5.0.1 has additional instances of {{data-pid="12345"}} format which causes 
key to be null when parsing projectPage. Adding ? before search pattern ?pid= 
fixes the issue by finding the required pattern {{?pid=12345&}}
Also Verified with older version of Jira 4.X

Jira 5 projectPage is as below...
{code}

  Task

{code}


  was (Author: swapsapar):
Attached patch with a simple fix for Jira 5.
-

Jira 5.0.1 has additional instances of data-pid="12345" format which causes key 
to be null when parsing projectPage. Adding ? before search pattern ?pid= fixes 
the issue by finding the required pattern ?pid=12345&
Also Verified with older version of Jira 4.X

Jira 5 projectPage is as below...
{code}

  Task

{code}

  
> jira report fails with Jira 5.0.3 (NPE)
> ---
>
> Key: MCHANGES-281
> URL: https://jira.codehaus.org/browse/MCHANGES-281
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira
>Affects Versions: 2.6
> Environment: OS: Mac
> Maven: 3.0.4
> Java: 1.6
> Jira: 5.0.3
> maven-changes-plugin: 2.6
>Reporter: Swapnil Sapar
> Attachments: MCHANGES-281-fix.patch
>
>
> Cannot generate jira-report or announcement-mail using Jira 5.0.3. These 
> goals worked perfectly with Jira 4.X
> {code}
> [INFO] --- maven-changes-plugin:2.6:announcement-generate (default-cli) @ 
> hello-world ---
> May 2, 2012 4:16:55 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> May 2, 2012 4:16:56 PM org.apache.commons.httpclient.HttpMethodBase 
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using 
> getResponseBodyAsStream instead is recommended.
> [ERROR] Error accessing http://jira.xy.z/jira/browse/ABC
> java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.jira.JiraHelper.getPidFromJira(JiraHelper.java:142)
>   at 
> org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:389)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.getJiraReleases(AnnouncementMojo.java:723)
>   at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:488)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   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:597)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> [WARNING] JIRA file codebase/target/jira-announcement.xml doesn't exist.
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure