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
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?
I have a gradle task (type - exec). In this task I start a WildFly server using a standart bat file (standalone.bat). The war file is already in deployments beforehand, so the server starts up and everything works fine.
The problem appears when I need to debug the actual application on the server. Running the gradle task in a debug mode doesn't help, as it can only debug the actual gradle task itself and not the application that it starts.
I know, there is a solution to this problem using an additional configuration that would allow me to debug a remote java application. However, the goal for me right now is to move eveything onto gradle tasks and not have any configurations set up in my IDE.
I need to be able to run a gradle exec task that would start up my server and than to debug whatever application it deploys. Is there a way to do this? Thank you in advance.
Note: I've never used Wildfly
Ultimately you'll want to edit standalone.bat so that you include an additional arguments to the java.exe invocation. Take a look inside standalone.bat many applications include a line commented out that you can uncomment to enable debugging.
Eg sample argument to add to the java.exe call
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044
You may wish to take a copy of standalone.bat which you call standalone-debug.bat which you invoke via gradle
Intellij is giving me errors all around for brand new kotlin/spring project and I cannot build or run the project from the IDE.
If I do it from the command line however, there are no issues and I can build and run the app.
'classpath' in 'org.gradle.api.artifacts.dsl.DependencyHandler' cannot be applied to '(groovy.lang.GString)'
'apply' in 'org.gradle.api.plugins.PluginAware' cannot be applied to '(['plugin':java.lang.String])'
Cannot access class 'java.lang.String'. Check your module classpath for missing or conflicting dependencie
Type mismatch.
Required:
java.lang.String
Found:
kotlin.String
Any ideas to what may be the issue?
I tried Kotlin multiplatform JVM type mismatch in InteliJ but doesn't seem to fix the issue.
UPDATE:
Cleared gradle caches, reinstalled Intellij, Import project that was created from start.spring.io with Gradle and Kotlin selected.
Using default gradle wrapper and project jdk (the path says jre)? gives me an error. Open gradle settings just opens the file explorer.
Using default gradle wrapper and machine local JDK same issues with the dependencies from above.
This issue comes up if you set up your own module inside IntelliJ and you think that since you are doing a Kotlin (Maven) project, the SDK should be set to Kotlin. Wrong!
The problem is shown in the first image. The project SDK is set to Kotlin.
Change it to Java. Probably any 8+ Java will be good enough.
This solves the IDE errors and the compiler errors as well.
Unset KOTLIN_HOME and other Kotlin- or Java-related settings you may have in your environment (env to check, unset NAME to unset.)
Then kill any Gradle daemon still running (pkill -f GradleDaemon) and test your Gradle build from the terminal. If all goes well, remove the .idea directory; restart IDEA, making sure to run it without the stray environment variables (for example, launch idea.sh from the terminal where you unset them); and re-import your project, with the choice of using the default Gradle wrapper.
If you need to use standalone Kotlin versions, installed for example through SDKMAN, consider taking the SDKMAN activation lines out of your shell init file (.bashrc for Bash) and into a standalone script (say, ~/bin/sdkman) that will also change your shell prompt (PS1 in Bash) to remind you that you have entered a SDKMAN-managed CLI session.
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 an application. I run it via
gradlew run-app
Or debug
gradlew debug-app
It works. How do I pass '-Xmx' argument into the application which I run (debug)?
Is it possible to do so without edditing build.gradle file?
I found this
Gradle unknown command-line option '-X'
I get a similar error when I try
gradlew debug-app -Xmx2000m
Error
FAILURE: Build failed with an exception.
* What went wrong:
Problem configuring task :debug-app from command line.
> Unknown command-line option '-X'.
I tried to create a file gradle.properties in GRADLE_USER_HOME directory (by default, it is USER_HOME/.gradle).
org.gradle.jvmargs=-XX\:MaxHeapSize\=4256m -Xmx4256m -Xms2000m
I also tried to org.gradle.jvmargs=-Xmx2000m in project folder gradle.properties.
And even then when I run an application, I see Commited Memory size is < 520 MiB
And this is when I run it as a normal Java App
In the second case, when I run the application as a normal Java app with -Xms, -Xmx, Commited Memory size is about 3.5 GiB because I passed -Xmx4512m -Xms2512m parameters.
Add this in your gradle.properties file :
org.gradle.jvmargs=-Xmx2000m
From here
org.gradle.jvmargs
Specifies the jvmargs used for the daemon process. The setting is
particularly useful for tweaking memory settings. At the moment the
default settings are pretty generous with regards to memory.
edit : my answer what about the gradle daemon jvm, not the app jvm. You have to use the jvmArgs property
The extra arguments to use to launch the JVM for the process. Does not
include system properties and the minimum/maximum heap size.
Firstly, thanks #ToYonos for leading me to the right direction.
Secondly, I found the solution here https://stackoverflow.com/a/9648945/4587961.
I ran my app from command line.
set GRADLE_OPTS=-Xms1724m -Xmx5048m
gradlew debug-app
Note, CMD Windows command SET works locally, so if you close your terminal, GRADLE_OPTS will not be set. For Linux, you can use
export GRADLE_OPTS=WHATEVER
This is what I wanted to achieve.
Using application plugin one can use applicationDefaultJvmArgs property
apply plugin: 'application'
applicationDefaultJvmArgs = ["-Xms1024m", "-Xmx2048m"]
The arguments will be applied to run task and to start script of your application
more info
In my case Invalidate cache and restart the android studio(which is automatically restarted) then the error will be gone after restarting the android studio
then