Federico Budassi
Federico Budassi

Reputation: 113

Custom Gradle "Copy" task copies outdated classes

I'm currently working on the migration of an Ant script to its corresponding Gradle version. Everything works fine with the exception of a custom Copy task, which is in charge of copying the generated jar file from build/libs to another directory (out of the project).

If, after a first build, I introduce a change in any java file, and try to execute

gradle clean build deploy

i see the build/classes *.class files are correctly updated, and the build/libs/template-util.jar as well. However, the file template-util.jar copied to /home/fbudassi/Downloads has (the most of the times) the old version of the class. Sometimes, after some changes (I don't really know where, because I've tried many many things), the copied jar is updated correctly.

This is my build.gradle:

apply plugin: 'java'
apply plugin: 'eclipse'

// Default task.
defaultTasks 'deploy'

// Configuration parameters.
group = 'com.rcs.template'
version = 'master'
sourceCompatibility = 1.7
targetCompatibility = 1.7

ext {
    // Manifest extra parameters.
    projectName = 'Template Util'
    vendor = 'Rotterdam Community Solutions'
    buildNumber = 10
    jarName = 'template-util.jar'

    // Dependencies versions.
    jacksonVersion = '2.6.0'

    // Deploy destinations.
    deployTo = ['/home/fbudassi/Downloads']
}

// Dependencies.
dependencies {
    compile "com.fasterxml.jackson.core:jackson-core:$jacksonVersion"
    compile "com.fasterxml.jackson.core:jackson-annotations:$jacksonVersion"
    compile "com.fasterxml.jackson.core:jackson-databind:$jacksonVersion"
    compile "org.slf4j:slf4j-api:1.7.12"
    compile "org.apache.commons:commons-lang3:3.4"

    testCompile 'junit:junit:4.12'
}

repositories {
    mavenCentral()
}

// Jar name and Manifest data.
jar {
    def buildDate = new Date().format("MMMMM dd yyyy")

    archiveName = jarName
    manifest {
    attributes 'Built-By': System.getProperty('user.name'),
        'Built-Date': buildDate,
        'Built-JDK': System.getProperty('java.version'),        
        'Implementation-Title': projectName,
        'Implementation-Version': "$project.version - $buildDate - build: $buildNumber",
        'Implementation-Vendor': vendor
    }
}

// Deploy task: copy jar to destinations.
task deploy(dependsOn: 'build') {
    deployTo.each { dest ->
        copy {
            from jar
            into dest
        }
    }
}

// Gradle Wrapper version.
task wrapper(type: Wrapper) {
    gradleVersion = '2.5'
}

Could you help me find an answer to the problem?

Upvotes: 1

Views: 1727

Answers (2)

Opal
Opal

Reputation: 84844

Excepting the fact that the jar is deployed in configuration phase (as Rene wrote) you can use a task of type Copy - DSL, Gradle Docs and benefit from outputs and up-to-date mechanism:

task deploy(dependsOn: 'build', type: Copy) {
    outputs.file(new File(dest)

    from jar.outputs
    into dest
}

Upvotes: 1

Rene Groeschke
Rene Groeschke

Reputation: 28653

you have to do the copy operation during the execution phase. the quickest fix might putting the task action into a doLast block:

// Deploy task: copy jar to destinations.
task deploy(dependsOn: 'build') {
    doLast {
        deployTo.each { dest ->
            copy {
                from jar
                into dest
            }
        }
    }
}

otherwise your copy operation will be executed already in the configuration phase (before the new jar is created) thats why the old one is copied. In general it is a good idea to switch your setup to use multiple tasks of type copy to do the deployment. this allows also that you can benefit from the up-to-date checking which is not used when doing a plain copy operation.

Upvotes: 1

Related Questions