I'm using Gradle to create a build script. I want to protect the script from wrong properties, one of the tasks in the script is simple Copy task and I notice that when I put non-exist directory as from parameter the task continue with Skipping task ':copySpecificPlatform' as it has no source files.
Is there a way to cause the copy task to fail in this case?
This worked for me:
task copySpecificPlatform(type: Copy) {
from 'source/directory'
into 'target/directory'
if(inputs.sourceFiles.empty) throw new StopExecutionException("No files found")
}
You can try:
task cp(type: Copy) {
from 'empty'
into 'target'
inputs.sourceFiles.stopExecutionIfEmpty()
}
Every Task has its TaskInputs which source files are a FileCollection that has special method which configures the desired behavior.
Related
I am writing a task to unzip a war file, remove some jars and then create a war from extracted folder.
task unzipWar(type: Copy){
println 'unzipping the war'
def warFile = file("${buildDir}/temp/libs/webapps/service-app.war")
def warOutputDir = file("$buildDir/wartemp")
from zipTree(warFile)
into warOutputDir
}
task deleteJars(type: Delete){
println 'deleting the logging jars'
file("$buildDir/wartemp/WEB-INF/lib/slf4j-api-1.7.5.jar").delete();
file("$buildDir/wartemp/WEB-INF/lib/logback-classic-1.1.7.jar").delete();
file("$buildDir/wartemp/WEB-INF/lib/logback-core-1.1.7.jar").delete();
}
task createWar(type: War){
destinationDir = file("$buildDir")
baseName = "service-app"
from "$buildDir/wartemp"
dependsOn deleteJars
}
For some reason, the jars are not getting deleted and the war file is getting created which only includes MANIFEST.MF and nothing else. What am I missing here?
First thing to note, is that your createWar task depends on deleteJarstask, but deleteJars doesn't depend on unzipWar. It seems, that if you call the createWar task it won't call unzipWar task and there will be nothing to copy or delete. Note that you have a MANIFEST.MF file, because it was generated by createWar task.
And the second thing is that you are trying to delete some files in the configuration stage of the build, though your unzipWar will do it's job in the execution phase. So your delete task will try to delete this files just before they are even unzipped. You can read about build lifecycle in the official userguide. So you need to rewrite your deleteJars task, to configure it properly. Take a look into the docs, it has an example how to do it.
So if you call a
file("$buildDir/wartemp/WEB-INF/lib/slf4j-api-1.7.5.jar").delete();
it tries to delete your files at the time it's called, because it's not a task property, but an action at the configuration.
To configure it you have to do something like:
task deleteJars(type: Delete) {
delete "$buildDir/wartemp/WEB-INF/lib/slf4j-api-1.7.5.jar", "$buildDir/wartemp/WEB-INF/lib/logback-classic-1.1.7.jar", "$buildDir/wartemp/WEB-INF/lib/logback-core-1.1.7.jar"
}
I’m getting the following error whenever I attempt to use a Copy task to copy a file into the root of a project (the same folder I’m running gradle from):
Failed to create MD5 hash for file content.
I thought this was related to the artifacts I was pulling from Artifactory, but that seems to be unrelated. I was able to get the same results with a minimal script.
Is there something obviously wrong with what I’m doing, or does Gradle intentionally disallow such things?
task fails(type:Copy) {
from 'build/someFile.txt'
into new File('.').absolutePath
}
task works(type:Copy) {
from 'build/someFile.txt'
into new File('.').absolutePath + '/output'
}
Short Answer: Don't copy into the project directory, you are best to use into "$buildDir/someFolder" so that the folder is isolated to this single task, and also so that it will be cleaned by gradle clean
Long Answer: At it's core, Gradle has the concept of an "UP-TO-DATE" check for every single task. If Gradle sees that nothing has changed since last time a task was executed it will use the old result instead of executing again.
UP-TO-DATE checking is implemented by taking a "hash" of the task inputs and task outputs. Since you are using into '.' that means that the entire contents of the project directory is considered a task output (bad)
Gradle uses the .gradle folder for temp files (eg task hashes) It's likely some of these files are locked for writing as Gradle is trying to also read the same files (to calculate the "hash" of the task outputs) causing the error you are seeing
* EDIT *
If you need to copy into the project directory for legacy reasons, you might use Project.copy(...) directly instead of a Copy task. You could manually manage the task inputs/outputs in this case
Eg
task customCopy {
inputs.file "$buildDir/someFile.txt"
outputs.file 'someFile.txt'
doLast {
copy {
from "$buildDir/someFile.txt"
into '.'
}
}
}
Can you believe it, the following works
task myCopy(type: Copy) {
from "$rootDir/app1/src/main/resources/db"
into "$rootDir/app2/src/test/resources/db"
}
test.dependsOn myCopy
and the following doesn't 🤦
task myCopy(type: Copy) {
from '$rootDir/app1/src/main/resources'
into '$rootDir/app2/src/test/resources'
}
test.dependsOn myCopy
I've a simple task in Gradle:
task cleanBuild(type: Delete) {
def build = ".src/buildfiles"
FileTree tree = fileTree (dir: dbEditorBuild);
tree.each { File file ->
println file
}
}
When I run it, I get this output:
:user:cleanBuild UP-TO-DATE
BUILD SUCCESSFUL
Total time: 1.656 secs
I've read the docs and it says that tasks results are cached for performance. I wanted to rerun the task, but I couldn't. And that was despite editing the task code. So, apparently, it seems that Gradle is not able to detect that the task has been changed, which kind of suck.
I've tried what others recommended, like adding this line to the task:
outputs.upToDateWhen { false }
But it doesn't have any effect.
You define a task of the type Delete, but you don't define any files to delete. That is the reason, why your task is always up-to-date, since it has nothing to do. You can define which files will be deleted via the delete method. Everything you pass to this method will be evaluated via Project.files(...):
task myDelete(type: Delete) {
delete 'path/to/file', 'path/to/other/file'
}
Please note, that your code example does not interfere with the up-to-date checks, it doesn't even interfere with the task at all. Since you are not using a doFirst/doLast closure, you are using the configuration closure of the task, which is executed during configuration phase. Since you are also not using any task methods, your code would mean absolutely the same if it would be placed outside of the task configuration closure.
As a small addition: Even if this specific problem is not caused by the Gradle up-to-date checks, there is a way to force Gradle to execute all tasks ignoring any task optimization: Simply add --rerun-tasks as command line argument, as described in the docs.
If you are trying to delete some additional files that are not deleted with a default clean task (because it deletes only the build directories) you can extend the clean task to delete other things as well.
clean {
delete += "$buildDir"
delete += "$rootDir/someDir/someClass.java"
delete += "$rootDir/otherDir
}
Or create a new task to delete files and dependOn it to put in the build lifecycle.
task deleteSomething(type: Delete) {
// to delete a file
delete 'uglyFolder', 'uglyFile'
// to delete a directory
delete 'uglyFolder'
followSymlinks = true
}
Be default symlinks will not be followed when deleting files. To change this behavior call Delete.setFollowSymlinks(boolean) with true. On systems that do not support symlinks, this will have no effect.
Or you can put the action into the execution phase, and delete it.
task cleanBuild {
def build = new File("$rootDir/src/buildfiles")
doLast{
build.deleteDir()
}
}
Also, be sure the task has something to do because if the task has nothing to do, there is nothing to delete etc it will print UP-TO-DATE #lu.koerfer answer explains it perfectly.
I've prepared a very simple script, that illustrates the problem I see using Gradle 1.7 (need to stick with it because of some plugins not yet supporting newer versions).
I'm trying to dynamically create tasks each of which corresponds to a file in the project directory. This works fine, but the tasks I create never get executed as soon as I assign them type 'Copy'.
Here is my problem build.gradle:
file('templates').listFiles().each { File f ->
// THIS LINE DOES NOT WORK
task "myDist-${f.name}" (type: Copy) {
// NEXT LINE WORKS
//task "myDist-${f.name}" {
doLast {
println "MYDIST-" + f.name
}
}
}
task distAll(dependsOn: tasks.matching { Task task -> task.name.startsWith("myDist")}) {
println "MYDISTALL"
}
defaultTasks 'distAll'
in this way my tasks do not get executed when I call default task calling simply gradle:
MYDISTALL
:myDist-template1 UP-TO-DATE
:myDist-template2 UP-TO-DATE
:distAll UP-TO-DATE
BUILD SUCCESSFUL
If I remove type Copy from my dynamic task (uncommenting the line above), my tasks get executed:
MYDISTALL
:myDist-template1
MYDIST-template1
:myDist-template2
MYDIST-template2
:distAll
BUILD SUCCESSFUL
(You'll need to create a folder name templates in the same directory where build.gradle is located and put couple of empty files into there in order to run the test)
According to the debug output:
Skipping task ':myDist-template1' as it has no source files.
Skipping task ':myDist-template2' as it has no source files.
So how can I specify source files and make my Copy tasks execute?
I've tried adding
from( '/absolute/path/to/existing/file' ) {
into 'myfolder'
}
to the task body, I've tried assigning task's inputs.source file('/my/existing/file') with no success.
Could you please advise on how to modify my simple script leaving dynamic task creation and keeping my dynamic tasks of type Copy?
Thank you!
Edit:
All right, this way the task gets called:
file('templates').listFiles().each { File f ->
task "myDist-${f.name}" (type: Copy) {
from f
into 'dist'
doLast {
println "MYDIST-" + f.name
}
}
}
but it looks I must always specify from/into. It doesn't suffice to do that in the doLast{} body.
A Copy task only gets executed if it has something to copy. Telling it what to copy is part of configuring the task, and therefore needs to be done in the configuration phase, rather than the execution phase. These are very important concepts to understand, and you can read up on them in the Gradle User Guide or on the Gradle Forums.
doFirst and doLast blocks get executed in the execution phase, as part of executing the task. Both are too late to tell the task what to copy: doFirst gets executed immediately before the main task action (which in this case is the copying), but (shortly) after the skipped and up-to-date checks (which are based on the task's configuration). doLast gets executed after the main task action, and is therefore clearly too late.
I think the following Gradle User Guide quote answers my question the best:
Secondly, the copy() method can not honor task dependencies when a task is used as a copy source (i.e. as an argument to from()) because it's a method and not a task. As such, if you are using the copy() method as part of a task action, you must explicitly declare all inputs and outputs in order to get the correct behavior.
Having read most of the answers to "UP-TO-DATE" Copy tasks in gradle, it appears that the missing part is 'include' keyword:
task copy3rdPartyLibs(type: Copy) {
from 'src/main/jni/libs/'
into 'src/main/libs/armeabi/'
include '**/*.so'
}
Putting from and into as part of the doLast section does not work. An example of a working task definitions is:
task copyMyFile(type: Copy) {
def dockerFile = 'src/main/docker/Dockerfile'
def copyTo = 'build/docker'
from dockerFile
into copyTo
doLast {
println "Copied Docker file [$dockerFile] to [$copyTo]"
}
}
Not the behavior I was expecting.
Using gradle 3.2.1
I'm adding a task to deploy war files to Tomcat .. the only thing that the task needs to do is copy the war file to the TOMCAT location.
There 2 ways that I can think of implementing this .. but being new to gradle, I'm not quite sure what's more conventional/right (or if it even matters).
task myCopy(type: Copy)
myCopy.configure {
from('source')
into('target')
include('*.war')
}
or
task myCopy{
doLast{
copy {
from 'source'
into 'target'
include '*.war'
}
}
}
In most cases (including this one), the Copy task is the better choice. Among other things, it will give you automatic up-to-date checking. The copy method is meant for situations where (for some reason) you have to bolt on to an existing task and cannot use a separate task for copying.
The code for your Copy task can be simplified to:
task myCopy(type: Copy) {
from('source')
into('target')
include('*.war')
}
UP-TO-DATE only verifies the file is in place but not if the files has changed
to avoid being cached with an old file use
outputs.upToDateWhen { false }