Gradle Cache Entry has 0 Bytes

Old Forum Archive
1

I’m using Gradle to deploy to Tomcat with the Cargo library. Every now and again we get the following error:

* What went wrong:
Execution failed for task ':copyWar'.
Cause: Could not resolve all dependencies for configuration ':publish'.
Cause: Could not resolve group:ch.hedgesphere, module:HSMtWebServer, version:latest.integration.
Required by:
    :build:unspecified
Cause: java.text.ParseException: [[Fatal Error] 7e4254cb6607c572a3c45570f612282b17ee36da:1:1: Premature end of file. in HttpResource: http://artifactory:8081/artifactory/gradle-snapshot/ch.hedgesphere/HSMtWebServer/5.2.0-20120208132235/ivy-5.2.0-20120208132235.xml
]

Looking at the XML file from Artifactory, it looks fine. If I go and look in the Gradle cache on our Windows 7 build server, I find the shortcut file, but it points to a 0 byte file.

Deleting the entire cache fixes the problem, but it is re-occurring about once per day.

Here’s the Gradle script we use:

apply from: '../HSMtBuild/hsserv-repos.gradle'
apply from: '../HSMtBuild/third-party-repos.gradle'
  def warFileName = System.getProperty('warFileName')
  configurations {
    publish
    classpath
    all*.exclude group: 'maven-plugins'
}
  configurations.all {
    resolutionStrategy.cacheDynamicVersionsFor 1, 'minutes'
}
  dependencies {
    publish group: 'ch.hedgesphere', name: warFileName, version: 'latest.integration', ext: 'war'
    classpath 'org.codehaus.cargo:cargo-core-uberjar:1.2.0','org.codehaus.cargo:cargo-ant:1.2.0','jaxen:jaxen:1.1.3', 'commons-logging:commons-logging:1.1.1'
}
  ant.taskdef(resource: 'cargo.tasks', classpath: configurations.classpath.asPath)
  targetWarFileName = System.properties['user.home'] + "/${warFileName}.war"
  task copyWar << {
    ant.copy file: configurations.publish.singleFile.path,
    tofile: targetWarFileName
}
  task install(dependsOn: copyWar) << {
      outputs.upToDateWhen { false }
          for (def attempt = 0; attempt < 3; attempt ++) {
        try {
            ant.cargo(containerId: 'tomcat7x', action: 'redeploy', type: 'remote') {
                configuration(type: 'runtime'){
                    property(name: 'cargo.servlet.port', value: '8080')
                    property(name: 'cargo.hostname', value: 'localhost')
                    property(name: 'cargo.remote.username', value: 'tomcat')
                    property name: 'cargo.remote.password', value: 'tomcat'
                                                                deployable(type: 'war', file: targetWarFileName) {
                        property(name: 'context', value: 'HSMtFlexWebServer')
                    }
                                     }
            }
            break
        }
        catch(Exception e) {
            println e
            if(attempt == 2) throw e
            Thread.sleep 15000
        }
    }
}
2

This doesn’t address your issue but as a side note there’s a Cargo plugin for Gradle.

3

cool - something to look at when I next update the script.

4

This looks similar to an issue caused by a Squid Proxy sending GZipped content even when the HTTP request included “Accept-Encoding: identity”. This has been fixed in Milestone 8, as Gradle now handles gzip-encoded responses.

So: - What version of Gradle are you running? - Do you access the internet through a caching proxy server?

Otherwise, the best way to see what’s going on would be the entire log file, running the build with ‘–debug’. Unfortunately this will create pretty massive files, which might be a pain given the sporadic nature of the failure.

5

Gradle 1.0-milestone-7

Our Artifactory server (default install of the latest version, 2.4.2) is running internally, so no proxy involved.

Since there’s no proxy involved and the problem is intermittent, I don’t see how the HTTP header issue would be related to this problem.

Is milestone 8 imminent? I’ll give that a go as soon as it’s released anyway.

6

There is already a Milestone 8 release candidate available: http://gradle.org/release-candidate.