[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52081 ]
Vincent Massol commented on MNG-678: ------------------------------------ Hi Bart, Good catch! The primary DNS provided by my ISP is effectively not responding to pings. I've switched the DNS and the m2 build was able to go futher but it still failed with the same error (just a bit further): [INFO] [deploy:deploy] [INFO] Retrieving previous build number from cargo-snapshot Uploading: scp://beaver.codehaus.org/home/projects/cargo/dist2-snapshot/org/codehaus/cargo/cargo-core-api-util/0.7-SNAPSHOT/cargo- core-api-util-0.7-20051126.195123-1.jar 11K uploaded [INFO] Retrieving previous metadata from cargo-snapshot [INFO] Uploading project information for cargo-core-api-util 0.7-20051126.195123-1 [INFO] Retrieving previous metadata from cargo-snapshot [INFO] Uploading repository metadata for: 'snapshot org.codehaus.cargo:cargo-core-api-util:0.7-SNAPSHOT' [INFO] Retrieving previous metadata from cargo-snapshot [INFO] Uploading repository metadata for: 'artifact org.codehaus.cargo:cargo-core-api-util' [INFO] ---------------------------------------------------------------------------- [ERROR] BUILD ERROR [INFO] ---------------------------------------------------------------------------- [INFO] Error installing artifact's metadata: Error while deploying metadata: Error performing commands for file transfer session is down Note: the build was very slow so I still suspect that there were some network latencies happening somewhere (could be beaver.codehaus.org to which I'm dpeloying). All this seems to point to jsch beeing overly sensitive to network conditions. In any case it's not working well enough to be usable right now. Thanks > scp intermittently failing deploying artifact > --------------------------------------------- > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0.1 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
