I'd like to build certain projects without the use of of Gradle daemon. I've read that this can be done either by command-line argument --no-daemon or by changing Gradle properties under .gradle/. I need to disable it for just some of the projects I build under the root project though.
Is it possible via settings.gradle/build.gradle settings or am I better off making custom build script?
You can simply add org.gradle.daemon=false to a gradle.properties file in the project root folder.
The daemon documentation mainly talks about disabling the daemon altogether on a machine but the gradle properties documentation indicates that the location where a property / value pair is declared is irrelevant, they are sourced from different location, with overwrite rules.
Related
the documentation shows that I can configure this via the gui here: https://www.jetbrains.com/help/idea/project-security.html
Each time I have gradle perform :runIde it launches a new IDE instance and I have to reconfirm the trusted project directory.
Is there a gradle flag or setting somewhere in the plugin project to set this once for all?
I am using a kotlin build.gradle.kts file
*I have configured the trusted root in my 'Parent' IntelliJ IDEA that launches the task, but it seems, is sometimes not carried over. Alternatively I would like this to be available when operating from the CLI aswell.
*I am using the :clean command alongside the :runIde command, would this affect the settings being erased?
Gradle has this new feature that listen to file system events instead of touching the filesystem to detect changes to local files.
It can be enabled on the command line with --watch-fs. How can it be enabled persistently in a file that I would check in source control?
As of today, with Gradle 6.5 you can enable the experimental feature by putting the following in gradle.properties in the project root, or in your ~/.gradle/gradle.properties file:
org.gradle.unsafe.watch-fs=true
The feature will eventually be enabled by default, and the property name will change (losing the unsafe part).
Blog post from May 2020 gives the property as this:
org.gradle.vfs.watch=true
https://blog.gradle.org/introducing-file-system-watching
and it's confirmed on the Build Properties list here (for Gradle 7.0 and up):
https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties
At my job we use gradle, so on my laptop I have a ~/.gradle/init.d folder which contains the init scripts that define our enterprise-wide configuration, such as the URL of the local repository, docker publishing rules, checkstyle rules, etc.
I want to use gradle for a personal project, so I don't want to use any of these init scripts. Here are the ideas I have come up with so far:
Rename ~/.gradle to ~/.gradle-work, create ~/.gradle-personal, and then symlink ~/.gradle to -work or -personal depending on what I'm doing.
Have ~/.gradle as my personal gradle settings, and create another gradle folder ~/dev/work/.gradle with all my work init scripts. Make sure $GRADLE_HOME is set to ~/dev/work/.gradle when running gradle for any work projects.
Some variant of 2 where gradle will automatically use ~/dev/work/.gradle if it detects that the project is in the ~/dev/work/ folder.
Option 1 feels quite clumsy. Option 2 feels very tedious to have to set or unset an environment variable whenever I want to use gradle. Ideally I would like something like option 3 where I don't have to do any fiddling around whenever I change between personal or work projects. Is this possible? Or is there another solution that could solve my problem?
In our CI environment, we currently have one build server (based on Atlassian Bamboo) and two SonarQube instances (versions 6.0 and 6.5). Initially, our CI server was configured to communicate with the 6.0 SonarQube instance. This has been configured in the /home/bamboo/.gradle/gradle.properties file on our CI server like this:
systemProp.sonar.host.url=<http url of SonarQube 6.0 instance>
systemProp.sonar.login=<username here>
systemProp.sonar.password=<password here>
Now we have another Gradle-based project running on our CI server which shall talk to the new SonarQube 6.5 instance. I tried configuring this but failed all the time.
Things I have done so far:
Added commandline arguments to gradle wrapper command:
I have tried adding -Dsonar.host.url=, -Dsonar.login=, -Dsonar.password= to the Gradle command. As this didn't seem to work, I have also tried to set commandline arguments as SonarQube system properties using -DsystemProp.sonar.host.url=, -DsystemProp.sonar.login=, -DsystemProp.sonar.password=. This didn't work either.
Added properties to the build.gradle file
- Added properties to the build.gradle file like this:
sonarqube {
properties {
property "sonar.host.url", "<http url of SonarQube 6.0 instance>"
property "sonar.login", "<username here>"
property "sonar.password", "<password here>"
...<other SonarQube analysis settings here>...
}
}
In all cases, the CI server talked to the wrong SonarQube instance (6.0). My question is, whether it is possible to configure a single project to talk to another SonarQube instance. As you have seen, we use Gradle 3.2.1 as a build tool. And we are using the org.sonarqube Gradle plugin too.
Thank you for any help.
André
Your first try did not work, because you set the system properties from the commandline, but setting it from the project properties later on resets the system properties to the configured values.
Your second try did not work, because the systemProp.sonar.login syntax is only suppored in gradle.properties files, not via -P commandline project properties.
Your third try did not work because the SonarQube scanner prefers the system property values over the value configured via the DSL, so that one can change what is configured in the build script with the help of local configuration.
You need to set the system properties in your build script manually, this then overwrite what was automatically set from the project property. Using the project gradle.properties file does not work as the user file overwrite the project file. So you need something like System.properties.'sonar.login' = '...' in your build script. You can either hard-code it there, or then use project properties that you can set in your gradle.properties file or via -P parameters.
Besides that, I'd never depend on having any configuration in Gradle User dir on a build server. Most buildservers use build agents that might run on distributed machines, so you would always have to make sure that all build agents are configured the same and so on. I'd always configure in the build setup of the build server the according configuration, either by setting system properties, or environment properties or commandline arguments.
Just my 2ct.
I have a Spring Boot project with gradle build tool. The JDBC url, username and password are kept in a property file which is not part of application it's a external property file, the path of the property file is taken from system properties as follows.
export _JAVA_OPTIONS=-DdatabaseConfiguration=db.properties
It is working if I run the application from terminal using gradle bootRun, but when I try to run from Intellij IDEA 13 gradle tasks its not working, the property value is null.
I tried the VM options in Run/Debug Configuration as in the below screen shoot its not working either
How can the JAVA_OPTIONS can be set in Intellij IDEA 13 gradle tasks.
This is because every time you use the Gradle tool window to kick off tasks in IntelliJ, it creates/overwrites the launch configuration for that task.
Basically, I've had to run from the Gradle tool window just once. Then I go into the failed Launch Config (shown in question) and enter the system property in the VM options. From there on out, I need to use that Launch Config to execute the task instead of the Gradle tool window.
Update: Even better solution:
Preferences->Build, Execution, Deployment->Build Tools->Gradle->Gradle VM options
Add your system properties there (i.e. -Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk)
Doing this will keep them from getting overwritten/lost in the Launch configs that the Gradle tool window generates.
Another thing to note is that using the Gradle tool window causes the commands to be run without access to Environment Variables. This can cause a lot of problems with builds that depend on these env vars.
I ran into this today with the appengine-gradle-plugin and had to put
-Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk
in the VM options because it was not seeing the env vars. From the command line, it picks up the env vars and works fine. This worked for my appengineRun task.
But it does not work for appengineUpdate since that gives another error caused by lack of env vars: Toolkit not found: apple.awt.CToolkit