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
Related
I'm trying to work out how to get Gradle to delete published artifacts from the local maven repository. I figured it should be as easy as setting up a delete task, but this doesn't seem to work...
task cleanMavenLocal(type: Delete) {
delete '~/.m2/repository/example'
}
If it's even possible from Gradle, any ideas how?
You can't do this with Gradle's Delete task since files passed to delete are interpreted relative to the current project directory (see Documentation).
However, Gradle build files are executable code. An ad-hoc task should do the trick.
task cleanMavenLocal {
doLast {
new File('~/.m2/repository/example').deleteDir()
}
}
I'm trying to figure out, what Gradle does with the files, which are located in src/main/resources directory.
The processResources task, added by the java plugin to the project, copies them to the build/resources/main directory.
The content of this directory is bundled into the jar file created by the jar task that is also added by the java plugin, and the resources can thus be loaded, at runtime, by the ClassLoader.
See the documentation of the java plugin.
it might do nothing with them, but ignore them - per default (with the Android plugin) that directory is called res, only the Java plugin would take the resources directory into account (the question does not indicate which plugin is used). otherwise it would run a processResources task on them; only res/raw is not being processed (copied 1:1).
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.
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)
I have Android Studio project, where I store (in separate folder) PHP files (implementing web services). The whole project is built and maintained by Gradle plugin to Studio.
How to make Gradle to deploy (copy) these files from project to external Apache \htdocs localisation? Is it possible to copy theses files during Gradle build process? if so, how to copy them only if there are differences between files in project folder and files in external \htdocs localisation.
I will appreciate any help.
Assuming your Apache server runs on the same machine, you can create a Gradle copy task to copy single files or whole directories to a specific location:
task copyWebFiles(type: Copy) {
from 'src/web' // source directory
into '../path/to/htdocs' // target directory
}
preBuild.dependsOn copyWebFiles // execute task before build
As part of your app's build.gradle file.