I am working on a project where there is a different gradle.properties file for each environment. The process seems to be to rename gradle.properties.env (for example) to gradle.properties as required.
I am new to Gradle so possibly this is the wrong approach more broadly, but for now, is there a way to tell ./gradlew to use a specific file as its gradle.properties e.g.
./gradlew --propertiesfile=gradle.properties.env
It is probably better to put the environment-specific property file in the GRADLE_USER_HOME folder (defaulting to $USER_HOME/.gradle). Configurations in this location take priority over the ones in the project folder.
Another option is to supply the individual properties as system properties or environment variables.
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.
I have local and global gradle.properties, the global one is needed to configure the proxy, but it also contains other parameters, wondering what happens if for the same settings you specify different values, which of the files will be in priority or maybe they are How do they merge?
my global gradle.properties
systemProp.http.proxyHost=hostname
systemProp.http.proxyPort=8080
systemProp.http.proxyPassword=password
org.gradle.parallel=false
my local gradle.properties
android.useDeprecatedNdk=true
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.jvmargs=-Xmx4096M
For example, which org.gradle.parallel will be used?
According to the Gradle properties, the gradle.properties files are applied in the following order:
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.
Because the properties in GRADLE_USER_HOME are applied after the ones in the project root, they override the ones defined in the project. Assuming that with global you mean the one in the GRADLE_USER_HOME directory and local the one in your project root, your value for org.gradle.parallel will be false.
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.
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).
mvn command, among others, have following options:
-f,--file <arg> Force the use of an alternate POM file. (This is for pointing file instead of default pom.xml file.)
-gs,--global-settings <arg> Alternate path for the global settings file. (This one is for pointing the settings.xml file, which is by default in .m2 directory.)
Still there is yet one config file uncovered by these options - .mavenrc
So, my question is - Is there a way to tell maven from which file it should get MAVEN_OPTS?
MAVEN_OPTS is a environment variable from the OS. You can set it anyway you want before launching maven.
In bash (linux):
export MAVEN_OPTS=...
On windows:
set MAVEN_OPTS=...
I think you could even edit the 'mvn' of 'mvn.bat' shell script to get different variables.
Starting with Maven 3.3.1, you can put these settings into the .mvn/maven.config file in your project repository.
References:
JVM and Command Line Options
MNG-5767