scpexe is a noop

I cannot reproduce that (Linux, maven-1.1-beta-3-SNAPSHOT, maven-artifact-plugin-1.7-SNAPSHOT). In particular, setting maven.repo.X.scp.executable to a non-existing script gives me a 'java.io.IOException: /home/theussl/exe.bsh: not found'. Any more information you can provide? Note however that you need maven 1.1 to use the artifact plugin >= 1.5.2.

According to Brett 1.5.2 is the last version to be usable with M102. No, I cannot use M11 since we use XML entities quite extensivly. Therefore I need an artifact-plugin, that is able to write resolved POMs to prepare the transition to M2.

BTW: The exec mechanism may be quite different in Linux.

You're right, 1.5.2 should work with m102. Any chance that you (or anybody) could confirm that it works on Windows with the latest setup? I'd like to release 1.7 (as a m11 plugin only) soon and this is the last blocker in the way. I'm wondering if we could insert another release (1.5.3) that works with m102 and has this problem fixed. Any thoughts?

Unfortunately we are stuck to M102 and I would really appreciate another compatible version 1.5.3...

Actually, everything works for me also with m102, artifact-plugin-1.5.2, scp and scpexe. I can't test with Windows though, so somebody else will have to look at that. For the scp problem, can you try to run the deploy with the -X option? This should give you the detailed reason why it failed to deploy to a particular repository.

Well, as already said, exec for Linux & Windows is quite different. For scp I have always an AuthenticationException for my privatekey and passphrase. I can use "ssh -i id_file" without problems though ...

===== %< ====
jar:deploy:
[echo] Deploying...
Using userBuildPropertiesFile: C:\Dokumente und Einstellungen\jos\build.properties
Using projectPropertiesFile: C:\Work\Projects\commons\test\project.properties
Using projectBuildPropertiesFile: C:\Work\Projects\commons\test\build.properties
Will deploy to 1 repository(ies): elsag
Deploying to repository: elsag
Failed to deploy to: elsag Reason: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: Auth fail
org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: Auth fail
at org.apache.maven.wagon.providers.ssh.ScpWagon.openConnection(ScpWagon.java:164)
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:123)
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:90)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deployFiles(DefaultArtifactDeployer.java:376)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.doDeploy(DefaultArtifactDeployer.java:324)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.handleDeploy(DefaultArtifactDeployer.java:131)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:102)
at org.apache.maven.artifact.deployer.DeployBean.deploy(DeployBean.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230)
at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Caused by: com.jcraft.jsch.JSchException: Auth fail
at com.jcraft.jsch.Session.connect(Unknown Source)
at org.apache.maven.wagon.providers.ssh.ScpWagon.openConnection(ScpWagon.java:158)
... 31 more

Hi Joerg
scp protocol works for me with maven 1.1
Do you have a key like :

----BEGIN DSA PRIVATE KEY----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,A3717E0DB09C17E4

XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX

----END DSA PRIVATE KEY----

It's an openssh key generated by the tool puttygen

I think we should separate the issues here: one is the scpexe problem, which is confirmed on Windows. For the scp one I am not sure.
Arnaud, did you check if scp works for you with maven 1.0.2? If this is not a m1.0 compatibility issue then we shouldn't schedule an intermediary 1.5.3 release for it.

For the original (scpexe) problem, can you check if MNG-1587 is related?

@Arnaud: My key looks exactly the same and was generated with Cygwin's ss-keygen. The file has Unix line endings though ...

@Lukas: scpexe works for me with M2 despite the fact that it insists on a key even if an agent is running (WAGON-27).

This problem is also explained here (but for maven 1.1 with the artifact plugin 1.8)

It will not be fixed for maven 1.0.x. Sorry.

Not a problem anymore, at least for me ... using M2 since 1 year

I believe this is actually not a bug. We experienced the same sort of behavior here today.

It's actually due to the fact that maven is using jsch and sending out plain-text passwords. Most openssh servers are configured by default to support SSH2 with keys and encrypted passwords.
I solve this problem by enabling the following options in /etc/ssh/sshd_config:
PasswordAuthentication yes
HostKey /etc/ssh/ssh_host_dsa_key
RSAAuthentication no
PubkeyAuthentication yes

Cheers!

scpexe does call an ssh executable and has nothing to do with jsch.

I'm sorry for not noticing you were calling scp.exe...
Hm... Well, if possible, I suggest you use scp via Maven 1.1 + JSCH. It works great for us!