Is there a possibility to override build script property? I'm trying to build jar archive of my project and I want to specify 'version' via command line.
When I have 'version' property defined in my build.gradle (or gradle.properties), properties provided via commandline using -D/-P are not applied. Final jar is always built with version specified in build.gradle (or gradle.properties) and command line version property is ignored.
Thanks
The Gradle override plugin will help you with that. It allows for overriding any property exposed by any Gradle domain object (e.g. project properties, task properties, extension properties etc.).
As explained in this answer:
https://stackoverflow.com/a/57674847/5562284
Don't set the version in build.gradle file if you want to change it later on via cli.
Setting version in gradle.properties instead works.
Related
Is it possible to place these settings which I currently have in gradle.properties in my settings.gradle.kts file?
org.gradle.parallel=true
org.gradle.caching=true
Thanks
No, this is not possible since gradle.properties configures the JVM that runs the Gradle build and settings.gradle.kts configures the project once the JVM has started and the build starts up. See the documentation on the build environment
In my experience you can't do it.
You can check the gradle properties in the official doc.
The configuration is applied in following order (if an option is configured in multiple locations the last one wins):
gradle.properties in project root directory.
gradle.properties in GRADLE_USER_HOME directory.
system properties, e.g. when -Dgradle.user.home is set on the command line.
These properties are used to sep up the environment for your build:
org.gradle.caching=(true,false)
org.gradle.caching.debug=(true,false)
org.gradle.configureondemand=(true,false)
org.gradle.console=(auto,plain,rich,verbose)
org.gradle.daemon=(true,false)
org.gradle.daemon.idletimeout=(# of idle millis)
org.gradle.debug=(true,false)
org.gradle.java.home=(path to JDK home)
org.gradle.jvmargs=(JVM arguments)
org.gradle.logging.level=(quiet,warn,lifecycle,info,debug)
org.gradle.parallel=(true,false)
org.gradle.warning.mode=(all,none,summary)
org.gradle.workers.max=(max # of worker processes)
org.gradle.priority=(low,normal)
Also you can apply the same rules to settings.gradle and settings.gradle.kts.In the documentation:
Gradle defines a settings file. The settings file is determined by Gradle via a naming convention. The default name for this file is settings.gradle.
The settings file is executed during the initialization phase.
And looking at the Settings class in the API documentation
There is a one-to-one correspondence between a Settings instance and a settings.gradle settings file.
You can check the properties that you can initialize with this file.
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.
We are migrating our project from Maven to Gradle. Our CI uses system properties like -Dwebdriver.type=firefox to set certain behaviour thus we don't want to hardcode such props in gradle.properties file etc. Is there a way to provide a system property with a dot in the name using command line?
If you run the following:
build.gradle:
logger.lifecycle("some.property ${System.properties['some.property']}")
with:
gradle -Dsome.property=lol
It should give you the expected output.
Is there an ANT equivalent basedir property in gradle?
${basedir}
I am trying to get the name of the directory where the build script is located.
Thank you in advance!
Depending on your exact needs, you could use buildFile.parent or projectDir. (The build file path defaults to "$projectDir/build.gradle" and can be reconfigured in settings.gradle.) See the Gradle Build Language Reference for which properties and methods are available on Project and other classes.
Here's my scenario:
Maven 2.0.9 is our build system
We install code to multiple environments
All of our environment-specific properties are contained in property files, one for each environment
We currently read these properties into maven using the properties-maven-plugin; this sub-bullet is not a requirement, just our current solution
Goal:
Perform certain parts of the build (ie. plugin executions) only for certain environments
Control which parts are run by setting values in the environment-specific property files
What I've tried so far:
Maven allows plugins executions to be put inside pom profiles, which can be activated by properties; unfortunately these must be system properties - ie. from settings.xml or the command-line, not from properties loaded by the properties-maven-plugin
If possible, we'd like to keep everything encapsulated within the build workspace, which looks something like this:
project
pom.xml
src
...
conf
dev.properties
test.properties
prod.properties
build-scripts
build.groovy <-- the script that wraps maven to do the build
install.groovy <-- ... wraps maven to do the install
Running a build looks like:
cd build-scripts
./build.groovy
./install.groovy -e prod
Is there any possible way to accomplish these goals with the version of maven we are using? If not, is it possible with a newer version of maven?
This isn't possible using just Maven. (See also How to activate profile by means of maven property?) The reason is that profiles are the first thing evaluated before anything else to determine the effective POM.
My suggestion is to write some preprocessor that parses your environment specific property files and converts them to the required system properties before launching Maven. This script can be included in your ~/.mavenrc so that it runs automatically before Maven is launched. Here is an example script that that assumes the properties file is in a fixed location:
properties=`cat /etc/build-env.properties`
while read line; do
MAVEN_OPTS="$MAVEN_OPTS -D$line"
done <<< "$properties"
If the properties file is not fixed, you'll just need to add something to the script to discover the location (assuming it is discoverable).