I'm trying to execute a Gradle command-line task -setupDecompWorkspace to set up Minecraft Forge, but the task gets stuck on decompileMC. I've tried the first solution from this issue, but it didn't work. The second solution suggest setting the GRADLE_OPTS environment variable to -Xmx2G. I don't exactly know how to do this. After searching online for a couple of hours I am still found with no answer. Even the official Gradle documentation doesn't help. Do I need to declare the variable in the gradle.properties file, enter it as a command-line argument or something completely different?
-Xmx2G is a JVM command line parameter, if you want to set it as a Gradle property just add it to the gradle.properties file in your project root:
org.gradle.jvmargs=-Xmx2G
You can also find some more useful information here: https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties
Related
Starting from version 2.9 of the SonarQube scanner it is possible to reference variables from within sonar-project.properties:
https://www.sonarsource.com/resources/product-news/2017/03/2017-03-15-sonarqube-scanner-2.9-released.html
To me, the obvious use case of this feature is to avoid having to declare the version of the project twice (once in code and once in sonar-project.properties).
For example, in Swift projects the version is defined in a .plist file as an XML value. Is there an obvious simple method to retrieve this value and reference it in the sonar-project.properties file?
Update: I have managed to get this to work in a TeamCity build (command line build step):
echo "##teamcity[setParameter name='env.APP_VERSION' value='$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "MyApp/Info.plist")']"
and then referencing the variable in sonar-project.properties:
sonar.projectVersion=${env.APP_VERSION}
No 'obvious simple method' that I can think of. One approach could be to have a small script picking the version from the .plist and setting it as an environment variable. Environment variable which can then be referenced from sonar-project.properties.
Along the lines of this answer (which works for me, BTW) and the javadocs, I tried
gradle.startParameter.consoleOutput = org.gradle.api.logging.configuration.ConsoleOutput.Rich
in my ~/.gradle/init.gradle. However, I still need --console=rich to get color output. Why?
Tested with Gradle 2.14.1 and 3.2.1.
Terminal is cygwin urxvt with TERM variable set to rxvt-unicode-256color.
Since Gradle 4.3 you can use org.gradle.console property in gradle.properties:
org.gradle.console=rich
A new console verbose mode will print outcomes of all tasks (like UP-TO-DATE) like Gradle 3.5 and earlier did. You can set this via --console=verbose or by a new Gradle property org.gradle.console=(plain rich verbose).
I am not sure if you can force the rich console from a gradle script, as the detection happens likely before the script is interpreted.
NativeServices class provides the integration with the console. If you look at the source code, there are two messages possibly printed in log:
Native-platform terminal integration is not available. Continuing with fallback.
Unable to load from native-platform backed ConsoleDetector. Continuing with fallback.
The latter might give you more information why. Try running the gradle script with --debug. You will likely find out that you are missing a native library that is either not available in cygwin or it is, but is not on library path.
I believe it works when you specify the rich console from the command line, because gradle forces the colours even though the console doesn't indicate it supports them.
Does it work if you don't use the cygwin console in Windows native command line or maybe GitBash?
There is a workaround how you can make this work. You can create an alias in cygwin that will always add the --console=rich.
If you are using gradle wrapper, you can edit the gradlew script and add the command line parameter. To make it automated, you can change the wrapper task to alter your script in the doLast part.
Create a file called gradle.properties inside your ~/.gradle/ folder.
Inside gradle.properties, add the line org.gradle.console=rich.
Each builds will run under --console=rich automatically because the new gradle.properties will be merged with the gradle.properties of your project.
If your project's gradle.properties contains the same tag as the local file, your project's will be used overriding the local file's
If you are on Linux/Mac set
alias gradle='gradle --console rich'
in your ~/.bashrc.
In Gradle Wrapper, add the following line:
org.gradle.console=rich
to ./gradle.properties in the root folder, where the gradlew script is located.
I have been struggling to understand where Maven (version 3.1.1) looks for the local settings.xml file on Windows 7. Can someone please explain what Maven is doing as it logs the below lines during the execution of any mvn command with the -X switch?
[DEBUG] Reading user settings from ???
Is it examining an environment variable to construct the path? If so, which one? I'm asking this because I was greatly surprised to see that it was examining the path
\\computername\userName\.m2\settings.xml
instead of the expected location on my C drive, which is
C:\Users\userName\.m2\settings.xml
As Tunaki has pointed out, Maven uses the Java system property ${user.home}, which does not always resolve to path that we might expect it to.
To force ${user.home} to be a different path, I had to add the environment variable "_JAVA_OPTIONS" and give it the value "-Duser.home=%UserProfile%", which is the path I thought it should have been looking in the whole time.
I have a go lang application which exposes a rest API and logs the information to DB. I am trying to convert the make file to gradle build. Is there any default way similar to maven2gradle plugin or the gradle build file should be written manually? I checked the syntactical differences between gradle and make file but still not clear about passing run time arguments to gradle that is similar to
run:build
./hello -conf=/apps/content/properties/prop.json -v=0 -logDest="FILE" -log_dir="/var/log/logdir"
hello is my executable and others are the runtime arguments. This is my first attempt in migrating make to gradle and I couldnt find any clear documentation. Please help.
As far as I have checked, there is no direct plugin that could do this task. As a workaround, the build execution could be written as seperate tasks in gradle and ordered accordingly. Tasks here would contain setting Go path, installing dependencies and building the application and would be run as command line process in Gradle. Gradle provides support to run command line processes as described in gradle documentation. Hope it helps.
I want that my jenkins job will use env variables from a properties file. is that possible, and how?
Thanks, Ohad.
EDIT: I want environment variables to be resolved when checkout from svn, so that few projects will have the same revision. I am trying to use a solution suggested here.
There are a couple of plugins used for this type of thing. You might want to take a look at the following two. I have feeling the one your looking for is the second one.
Setenv
Envfile
If you want to get all manual about it you can also do this.
Manage Jenkins -> Configure System -> Global Options -> Environment variables
Goodluck!