We use external SCP program to externalize credentials management from Maven
configuration. Hudson Maven plug-in embeds an old version of Maven, which has
problems with escaping of commands produced by the external SCP deployer. The
issue is a combination of the following:

0) scpexe-URLs get deployed with Wagon-ssh-external, which uses Plexus-utils to
create command lines
1) Maven modules of Hudson jobs are located in directories named
groupId$artifactId on the filesystem
2) Old versions of Plexus-utils command line utility does not escape $ in shell
arguments

1) and 2) together cause $artifactId to be environment-expanded when the SCP
command line is executed. The replacement is usually empty string. The result is
that the command line to tries to change to nonexistent directory and the
deployment fails.

Example stack trace below:

Deploying artifacts to scpexe://server/dir/to/indagon-maven-snapshots
Deploying the main artifact someartifact-1.1-SNAPSHOT.jar
[INFO ] Retrieving previous build number from maven-snapshots
[INFO ] repository metadata for: 'snapshot
com.indagon:someartifact:1.1-SNAPSHOT' could not be found on repository:
indagon-maven-snapshots, so will be created
ERROR: Error deploying artifact: Exit code: 1 - /bin/sh: line 0: cd:
/path/to/.hudson/jobs/someartifact-trunk/modules/com.indagon/builds/2009-11-15_03-52-35/archive/com.indagon/someartifact/1.1-SNAPSHOT:
No such file or directory

org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying
artifact: Exit code: 1 - /bin/sh: line 0: cd:
/path/to/.hudson/jobs/someartifact-trunk/modules/com.indagon/builds/2009-11-15_03-52-35/archive/com.indagon/someartifact/1.1-SNAPSHOT:
No such file or directory

at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94)
at hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:119)
at
hudson.maven.reporters.MavenAggregatedArtifactRecord.deploy(MavenAggregatedArtifactRecord.java:79)
at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:96)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:480)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:466)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:590)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:438)
at hudson.model.Run.run(Run.java:1140)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:300)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:122)
Caused by: org.apache.maven.wagon.TransferFailedException: Exit code: 1 -
/bin/sh: line 0: cd:
/path/to/.hudson/jobs/someartifact-trunk/modules/com.indagon/builds/2009-11-15_03-52-35/archive/com.indagon/someartifact/1.1-SNAPSHOT:
No such file or directory

at
org.apache.maven.wagon.providers.ssh.external.ScpExternalWagon.executeScpCommand(ScpExternalWagon.java:236)
at
org.apache.maven.wagon.providers.ssh.external.ScpExternalWagon.put(ScpExternalWagon.java:295)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244)
at
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
... 12 more
Finished: FAILURE

The correct path to 'cd' to in the example above would have been
'/path/to/.hudson/jobs/someartifact-trunk/modules/com.indagon$someartifact/builds/2009-11-15_03-52-35/archive/com.indagon/someartifact/1.1-SNAPSHOT'

I see two possible fixes to the problem:
1) Change Hudson to not use $ in path names
2) Change Hudson to use newer Maven (perhaps system Maven? why is Maven embedded
in the plug-in anyway?)

1) is rather silly, and would probably be backwards-incompatible (although
reading of $-separated module names could still be supported), and would require
finding some other separatorthat isn't used in any project, and doesn't get
special treatment by shells
2) I don't know about. On the surface it looks like the Right Thing to do, but
probably there is a reason why a specific, old version is embedded in the
plug-in in the first place.