using Gradle, i have externalized properties in gradle.properties, for example:
version=0.157.4
org.gradle.jvmargs=-Xmx2G
Is there a way to update a property in the file, preferably using Gradle ?
I would like to be able to do something like gradle -Pversion=0.158.0 update gradle.properties, and would expect that the only thing that gets done is the gradle.properties file is updated to:
version=0.158.0
org.gradle.jvmargs=-Xmx2G
Related
I am trying to parameterize my build.gradle file with variables from my applications.properties file. Let's say I have a variable: flyway.user that is set in application.properties. How can I include this in the build.gradle file?
My view - This is the other way around.
Gradle build + flyway - would only apply in local DEV / CI build.
All other ENV will drive via non-gradle tools.
its better to keep ENV defined in GRADLE_HOME (~/.gradle) gradle.properties
During build these are available in gradle project - to all tasks
Also - you can tokenise the application.properties and replace values (for DEV)
additional benefit is that if multiple developers are working - each can have their own config without any code change.
~/.gradle/gradle.properties >> gradle :project >> tasks (flyway, processResources)
(I use the above - for my flyway in our team)
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.
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 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.
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).