Wednesday, November 2, 2005

Eclipse, ANT and sshexec

It took me quite a while to figure out how to make eclipse work with sshexec targets on ant build files. Turns out it was quite easy and even uses the cached identity used for cvs operations. Quite handy. The way I made it work was to tell the ant builder to make use of the jsch jar included in eclipse for use by the cvs plugin.


  1. Open Window -> Preferences

  2. Select Ant -> Runtime on the left side

  3. In the classpath tab, select Ant Home Entries

  4. Click on the Add External JARs... button

  5. Navigate to your eclipse installation, then select eclipse/plugins/ org.eclipse.team.cvs.ssh2_3.1.0/jsch-0.1.18.jar

  6. Click okay to confirm the file selection

  7. Click okay to close the preferences dialog

  8. Run your buildfile with sshexec and/or scp tasks.



It's that easy. The specific version number of the cvs/ssh plugin and the jsch jar may differ, but it should still work.
Posted by at
Labels:

3 comments:

  1. patDecember 18, 2005 at 4:04 AM

    nice one.

    If you keep getting the error about authentication, you have to turn on PasswordAuthentication in the ssh server config file.

    ReplyDelete
  2. Alan WesthagenJuly 27, 2006 at 6:17 AM

    I followed the instructions for Eclipse, Ant, and sshexec.

    The name of the jar that I found in my Eclipse plugins was identical to the one in your instructions. I am running Eclipse 3.1 on a RHEL4 Linux box. I do not use cvs.

    When I attempt to run sshexec from an Eclipse project with the following build.xml target:





    I invariably get this error:

    com.jcraft.jsch.JSchException: java.lang.ArrayIndexOutOfBoundsException: 1024

    This also occurs if I use an explicit password rather than
    a keyfile.

    What am I missing?

    ReplyDelete
  3. caskeyJuly 29, 2006 at 8:43 PM

    I've seen this error with ant before, it's confusing, but it comes from having a semantically invalid scp target in the build.xml

    In my case, I was using *both* the remoteToDir and remoteToFile in an attempt to rename a file at the destination. Turns out that the remoteToFile can contain the remoteToDir as a prefix. If you have both present, then what should simply be noticed as an illogical combination of attributes is instead turned into an obscure error.

    Double, and triple check that you have a well formed scp task. However, the documentation for scp does *not* make it clear what valid combinations there are.

    ReplyDelete

Subscribe to: Post Comments (Atom)