Last week Wilfred and I spent some time to understand why the Maven2
mvn site:deploy command would not work when
scp was used to access the target server. Based on the documentation we put:
<servers> <server> <id>server-id</id> <username>gumpy</username> <password>hushhush</password> </server> </servers>in the
~/.m2/settings.xmlfile and included
<distributionManagement> <site> <id>server-id</id> <name>Deployment Server</name> <url>scp://server-id.domain.com/home/gumpy/projects/</url> </site> </distributionManagement>in the projects POM. Looks OK, right? Well, while using commandline
sshworks using the credentials above,
mvn site:deployfails saying it cannot authenticate (and lists the supported authentication methods).
After a number of attempts we decided to try the private key authentication method in combination with an external scp command. This worked! It might not be what you want in the end, but at least we could continue. Small advantage of this solution might be that you don't have to include a password in your
~/.m2/settings.xml file. On the other hand, everybody who wants to deploy the site has to get their public key included in the servers
~/.ssh/authorized_keys file, which might be a disadvantage.
<servers> <server> <id>server-id</id> <username>gumpy</username> </server> </servers>And this is the projects POM snippet (note that
scpexeindicates that an external
scpcommand must be used):
<distributionManagement> <site> <id>server-id</id> <name>Deployment Server</name> <url>scpexe://server-id.domain.com/home/gumpy/projects/ </site> </distributionManagement> <build> <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ssh-external</artifactId> <version>1.0-alpha-5</version> </extension> </extensions> ... </build>In addition to these changes to the
settings.xmland the projects POM file we had to include the SSH public key of our development machines in the
.ssh/authorized_keys2file of the "gumpy" user on the
server.domain.commachine. A howto for "SSH without a password can be found here.
I suspect that the above is just a temporary workaround till the Maven 2 site:deploy plugin is fixed.