If I have a simple gradle file that contains
task mytry(type:Copy){
from '/tmp/try'
into '/tmp'
}
and I have a file /tmp/try/1.txt
I expect this to copy /tmp/try/1.txt to /tmp/1.txt
However, it scans all of /tmp (the into param) before doing the copy.
There are files in /tmp (such as /tmp/.X11-unix/X0) that gradle cannot access, and so it fails.
How to I tell the copy task to not scan the into directory?
I've tried 'include' 'exclude **'
(This is an example of my real problem, the real issue is that in my project the 'into' is a massive directory with many subdirectories and gradle is scanning every single file which takes forever)
gradle version 1.12 (v2 is not an option yet)
Related
I have this kotlin gradle build script representing my use case.
I am working with Gradle 6.7.
This is my kotlin gradle build file:
plugins {
java
}
tasks.register("createFile"){
doLast{
projectDir.resolve("tmp.txt").createNewFile()
projectDir.resolve("tmp.txt").writeText("tmp")
}
dependsOn("assemble")
}
tasks.register("createExecFile", Exec::class){
workingDir(buildDir)
commandLine("cmd", "/c", "mkdir destdir\\subdir")
dependsOn("createFile")
}
tasks.register("copyBug", Copy::class){
from(projectDir.resolve("tmp.txt"))
into(buildDir.resolve("destDir"))
dependsOn("createExecFile")
}
Now run gradle copyBug -i.
The first time this will give you this output:
> Task :copyBug Deleting stale output file: E:\repo\BugCOpy\build\destDir Caching disabled for task ':copyBug' because: Build cache is disabled Task ':copyBug' is not up-to-date because: No history is available.
The copy task deletes the file created by the previous exec task.
Now if you rerun this command the copy task won't delete stale file.
So what are those stale file? How can I prevent those file to be deleted? My first build and is different than the other build.
Should I file a bug?
In your createExecFile task you produce output files without telling Gradle about them. So Gradle doesn’t know that this task and the copyBug task use the same output directory. Instead, Gradle believes that copyBug is the only task producing outputs under build/destdir and hence it’s safer to assume that any existing files in that directory should not be there (and are “stale”).
The solution is to tell Gradle that your createExecFile task outputs to build/destdir:
tasks.register("createExecFile", Exec::class) {
workingDir(buildDir)
commandLine("cmd", "/c", "mkdir destdir\\subdir")
// tell Gradle about the output directory
outputs.dir(buildDir.resolve("destdir"))
dependsOn("createFile")
}
See this release notes section for why this behavior was introduced and this explanation to a very similar issue if you want some more background information.
My build process looks like
run gradle (part 1)
do something else
run gradle (part 2)
For me annoyingly running gradle in step 3 would not just add a few files to the output directory but delete that folder as stale first. Even adding
outputs.dir(...)
did not prevent Gradle from removing it as stale. Working out the inputs and outputs of my task looked too tedious, but luckily I found a way to tell Gradle not to perform any up to date tracking:
Example 37. Ignoring up-to-date checks mentions to add
doNotTrackState("Comment why this is needed")
which ultimately helped me to keep the files from build step 1.
I have the following task:
task copyToLibs(type: Copy) {
into "libs"
from configurations.compile
}
My libs directory already contains a few unique (not part of my gradle dependencies) libraries. When I run the gradle task, gradle copies all of my dependencies to the libs directory as hoped for. The problem is that after the copy, each of my pre-existing jar files now have zero bytes. They were fine before running the task. I checked, the files are not located under ~/.gradle. Why would running that task zero out my pre-existing jar files?
Thanks!
Blake McBride
I have a non-source configuration file that affects how my project is built. If I change that file and run Gradle (when the source files haven't changed), then it doesn't recompile at all. What can I do in my build file that will make Gradle treat changes to that config file as if they were changes to source files?
More simply, perhaps, how do I get Gradle to watch a particular (non-source) file so that changes to that file trigger an out-of-date compilation to occur?
You can simply add files as task inputs via the methods file(Object), files(Object...) and dir(Object) of the TaskInputs object of any task (accessible via task.inputs).
Just decide which task is the first one to depend on the file(s) as input(s).
I have a multi project Gradle build script that runs successfully on Windows 10. It reads and updates a Version.properties file that is located away from project managed directories.
All file manipulations are done using Gradle/groovy. After the Version file has been read, incremented and rewritten it is copied to a build/classes directory where it will be picked up by subsequent jar and shadowjar tasks.
Everything works as advertised if I invoke gradle as follows:
gradle build shadowjar ... etc.
However, if I invoke the clean task prior to build the file is read and incremented properly but the copy of the file fails silently.
The command used is:
gradle clean build shadowjar
My suspicion is that gradle does not wait for the clean task to finish prior to starting the build task. The file gets read and incremented but meanwhile, the multi-project clean activities have not yet finished. I have tried variations on dependencies{} blocks, doFirst{} and doLast{} to try and push the file copy back further in the build process. My main requirement is to have the Version.properties file in place prior to the jar or shadowjar task executing. I'm suspicious of trying to write into gradle's build/ directories in that it might not be possible to put anything into the build directories while gradle is performing its activities. Is there any way to ensure that the Version.properties file (or any generated file) gets copied? Or is there another location that I can use that will not be blown away by gradle at clean time yet still get picked up in the build:jar / build:shadowjar?
You are not supposed to call gradle clean 99.99% of the time, it is redundant due to gradle's incremental build feature. So as long as you correctly define your task inputs and outputs and start from ground up in each task, the problem solves itself.
Anyway in your case the wrong order could be caused by dependency between clean and other tasks, is there any?
I have found a way to write out a generated Version.properties file that will get picked up by the jar and shadowjar tasks. Use the gradle copy task and place the revised Version.properties file into a resources directory. The build activity includes the files found in resources/ in subsequent tasks (jar, shadowjar, test, etc.) My suspicion is that because clean blows away build directories gradle assumes that the activity has fully completed when it starts the build. I think that I've proven that this is not the case. doFirst{}, doLast{} and dependencies{} do not seem to work as modifiers to clean build.
Gradle created a ?/.gradle/ in the directory that gradle was run in. We would expect the cache directory to be created at ~/.gradle.
Example:
/project # Project root and cwd when running gradle command
/.gradle # Expected - project-specific gradle folder
/? # Directory literally named with a question mark
/.gradle # Unexpected - Global gradle folder with wrappers and cached artifacts
The user running the scripts did not have a home directory, giving the user a home directory or specifying a gradle-user-home solved the issue:
gradle --gradle-user-home=/foo/bar ...
or
GRADLE_USER_HOME=/foo/bar gradle ...
There are two different folders gradle stores information. ~/.gradle is used to store downloaded artifacts, gradle wrappers, etc. Basically everything that can be shared between multiple builds. The .gradle folder in your project is used to store project specific information used for example by the gradle up-to-date check mechanism.
let's find it out why it behaves like this.
As gradle use following code to get user home:
System.getProperty("user.home");
Follow the link for openjdk 8 source code.
It comes to conclusion: When JVM can not found user name in os, it will use ? as a return. So gradle will create ?/.gradle for usage.