I updated gradle locally by changing the version in my build.gradle file here:
wrapper {
gradleVersion = '5.6.1'
}
Next I was not able to build directly due to errors, but my IDE noticed that the version of gradle has changed and offered to install it through a popup. After that everything worked.
When I pushed my changes to my autodeployment tool it currently builds the project by executing:
call gradlew clean war
But I'm getting the same errors and this time there's no smart IDE to come to the rescue :D Therefore my question:
How can I make sure my gradle always updates to the version that is defined in build.gradle before trying to build?
The version of Gradle that is used by the wrapper script is the one defined in the file gradle/wrapper/gradle-wrapper.properties.
When you want to update Gradle, you could go manually changing that file, but this won't update the actual wrapper script and jar file. So it is a better practice to run ./gradlew wrapper, which will update gradle-wrapper.properties and, if needed, the other support files as well.
To tell the wrapper task which version you want to use upgrade to, you can either use a command line parameter, or do what you are doing and keep the version in the build.gradle file (this is always what I do as well).
I usually run the wrapper task twice: first to update the version and second to both download the new version and then regenerate the scripts from this new version.
Remember to commit all files changed by the wrapper task, which could be gradlew, gradlew.bat and the two files in the gradle/wrapper folder.
Related
Everytime I check out and open a project in Intellij I need to change the gradle plugin setting "Use Gradle from" from the default "'gradle-wrapper.properties' file" to "'wrapper' task in Gradle build script"
Is there a way in Intellij 2020 to make the shown option the default?
Reason I am asking: Generated gradle-wrapper files are not in our VCS, but the build.gradle is, and it has the wrapper task configured with the desired version. So when I check out a project, Intellij does not find gradle.properties (and neither can download gradle from web, as that is blocked). I then have to change the option "Use Gradle From" manually each time.
Another solution I tried is to automatically run a script when opening a module, which would run gradle wrapper with a fixed gradle version for the module, hence generating the missing wrapper files. But I find no possibility in Intellij to trigger that upon import..
It is not possible to change this setting for all projects. Please vote for this request: IDEA-215792.
We wired https://github.com/sherter/google-java-format-gradle-plugin into our project per the readme.
We also wired in a pre-commit hook to run the plugin before committing, which ensures that all of the code in a changelist is formatted before pushing it, which avoids errors in Jenkins when we run the verGJF task.
But we have to keep remembering to run goJF locally before running ./gradlew build, or the build fails with formatting errors.
We worked around this by adding the https://plugins.jetbrains.com/plugin/8527-google-java-format and https://plugins.jetbrains.com/plugin/7642-save-actions plugins for IntelliJ, enabling the google-java-format plugin, and configuring the save-actions plugin to format on save.
But that's a lot of extra configuration a developer has to remember to go through, plus it means they can't format code the way they want while working on it, and only have it be reformatted at the point of build or commit.
We'd prefer an all-Gradle solution, so that the goJF task is run before the build task (and before the verGJF task, which is already bound to the build task by the google-java-format Gradle plugin).
We couldn't figure out how to do that. Does someone else know?
It sounds like you want to essentially always ensure that the code is properly formatted before the verifyGoogleJavaFormat task is run (and could complain). In that case, I’d simply make the googleJavaFormat task a dependency of the verifyGoogleJavaFormat task. In your build.gradle file, after you have applied the google-java-format plugin, simply add the following:
verifyGoogleJavaFormat.dependsOn(tasks.googleJavaFormat)
Alternatively, if you really only want to run the code formatter when the build task is run (as opposed to when the verifyGoogleJavaFormat task is run only), you could add this instead:
build.dependsOn(tasks.googleJavaFormat)
verifyGoogleJavaFormat.mustRunAfter(tasks.googleJavaFormat)
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.
I need to execute groovy script with gradle, but the thing is that these scripts are located in external directory (let's say it's Desktop). I've heard, that in previous versions of Gradle (currently working on 3.2.1) it was not possible, since it is not part of the gradle project. I wonder if it is possible now, or do I have to copy all these scripts into some folder located in gradle project, to execute it.
User story:
I found script in external directory (based on some properties passed to console) - I have absolute path to the script
Now I want to execute this script (build.gradle) without copying it into my gradle project
I'm pretty green with gradle and I hope I made my point clear.
Thanks for help and every attempt :)
Is that what you're looking for? To run the script clone the repository, navigate to 42556631/project folder and run the command:
gradle -b ../script/build.gradle clean build
yes you need to move build.gradle file into project/Build Script folder and then run it.
We would like to have a script that does "svn update" and if the depedency.gradle file is in that list of updates, we would like to run a task that ONLY updates dependencies so the developers machine is up to date. What would that task be? I don't see it when running "gradle tasks". Looking for an updatejars or something.
When we build our project, we don't want it to check for jar updates at all!!!! most because that only needs to be done in 2 situations which are #1 above and when someone is updating the dependency.gradle file themselves. For the second thing, they can just run "gradle updatejars" once I know the answer to question #1 that is.
Any ideas? I am just getting into gradle and we really want to keep a consistent environment where when we run our update script, it gets the source code AND the jars in one atomic sweep and we are no longer bothered by checking the repositories every build.
It would be nice to know how to do it by changing the build.gradle file if possible. If not, is there a command line option? (The build.gradle obviously would give me a command line option which is why I prefer that method as I could say compile does not depend on downloading jars).
Regarding the second question. As far as I understand, Gradle will not attempt to do remote lookups or try to download the jar if it is already in the local cache. This should be true for jars declared with a static version, e.g. testCompile 'junit:junit:4.10'.
If you have dynamic versions, e.g. 1.+ or 1.0-SNAPSHOT, etc. then Gradle has to do a check every now and then. You can fine tune the cache expiry for such dependencies.
To make sure Gradle does not do remote lookups you can also use --offline option. See this doc for details.
With regard to svn update, you have at least 3 options:
Try to use an SvnKit plugin for Gradle
Use the ant svn task (here's how to do svn checkout)
Run external command from Gradle. Use the ExecPlugin or just implement it yourself using Groovy API.
Looks like the 1st question I can do with the answer in this post
how to tell gradle to download all the source jars
so I can just gradle eclipse and it will download new jars and update my classpath...nice.