Building with Java 7 and keep getting Kerberos prompt for ssh authentication to our Ivy repository

Old Forum
1

Hi, we have a Java build and use an Ivy repository (which we connect to using an SshResolver). Our build runs fine using Java 6, however when we’ve tried to upgrade to Java 7 the build keeps pausing with a Kerberos prompt as follows. The build only works if the user hits return after each prompt.

Kerberos username [andys]:
> Building > :uwm/core:compileJava > Resolving dependencies ':uwm/core:compile'

The build is being run from a Windows PC and is configured to use an SshResolver to retrieve the dependencies from an Ivy repository on a Solaris box.

repositories {
              add(new org.apache.ivy.plugins.resolver.SshResolver()) {
            name = 'ivy_repo'
            user = 'orchard'
                userPassword = 'xxxxxxx'
//plain text password
            addIvyPattern
    "/uwm/ivy-repo/[organisation]/[module]/ivys/ivy-[revision].xml"
            addArtifactPattern "/uwm/ivy-repo/[organisation]/[module]/[type]s/[artifact]-[revision](-[classifier]).[ext]"
            host = "junior"
        }
            }

I’ve tried using an SftpResolver but get the same problem. The user name setup in the SshResolver is ‘orchard’. The Kerberos prompt has the username of the person running the build. We are currently using gradle-1.0 (but I’ve tested against 1.1 and get the same problem).

I think this is an issue with the jsch.jar and Java 7, see this post: https://issues.apache.org/bugzilla/show_bug.cgi?id=53437

Is there any way I can apply the suggested workaround in our Gradle build or would this need a fix?

Has anyone else encountered this and managed to work-around it? My only other alternatives seem to be either move the Ivy repository to a Windows PC and use a FileSystemResolver or install Artifactory just to make use of the Http resolver.

Thanks,

Richard.

2

Hi Rich - I’m experiencing the same problem too - did you find a solution to this problem?

3

Hi, No I haven’t found a solution yet. I’m not sure whether to raise an issue with the Gradle team, the Jsch developers or Ivy developers. I’m using an Ivy resolver, which is using the jsch JAR.

I notice jsch has recently released version 0.1.49 (see http://www.jcraft.com/jsch/) and Gradle uses jsch 0.1.46. I can’t see anything in the jsch release notes that looks like this issue but would like to test it out to see if it fixes the problem, however simply dropping the jsch jar into the Gradle lib directory didn’t work (I got errors that the 0.1.46 version couldn’t be found - I’m guessing it’s referenced in the manifest of another JAR).

If I do raise the issue with Ivy or Jsch I’ll post a link to the issue here.

4

If your team is bigger than one person, I strongly recommend to install an artifact manager like Artifactory. It solves the concrete problem, has many other advantages, and allows you to use Gradle’s direct Ivy repository support, rather than using an Ivy resolver.

5

Hi Peter,

Thanks for the response. As a workaround for now I’ve switched to using a resolver like this:

ivy {
    name = 'ivy_repo'
    url "//ourserver/uwm/ivy-repo"
    layout 'pattern', {
      artifact "[organisation]/[module]/[type]s/[artifact]-[revision](-[classifier]).[ext]"
      ivy "[organisation]/[module]/ivys/ivy-[revision].xml"
   }
}

So instead of an SSH resolver I’m using the standard Gradle ivy resolver but with the URL set to the full path of our Ivy repository (which is on a Solaris box mounted on the Windows network). In order to get an upload to work this way I had to modify the permissions on our Ivy repository to allow full write access.

Are there any issues with this approach and the Gradle cache? Does gradle still cache files if a file system path is specified for a URL?

I’ve looked into using Artifactory but must admit I don’t really get it or understand what it gives us. Am I right in thinking we’d still need our Ivy repository and that Artifactory is basically a server on top of our Ivy repository? What other advantages have you seen using Artifactory?

Thanks, Richard,

6

Does gradle still cache files if a file system path is specified for a URL?

Not sure. Easy to find out by looking under '~/.gradle/caches/artifacts-x/filestore.

Artifactory is basically a server on top of our Ivy repository? What other advantages have you seen using Artifactory?

Artifactory is an Ivy (and Maven) repository. It’s free, easy to install, gives you a handy UI for managing your dependencies and for troubleshooting resolution issues (log view), can act as proxy for other repos (e.g. Maven Central), can minimize network traffic due to its Etag support, etc. etc. I consider it a no-brainer, even for smaller teams.