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.
Related
Everytime I check out and open a project in Intellij I need to change the gradle plugin setting "Use Gradle from" from the default "'gradle-wrapper.properties' file" to "'wrapper' task in Gradle build script"
Is there a way in Intellij 2020 to make the shown option the default?
Reason I am asking: Generated gradle-wrapper files are not in our VCS, but the build.gradle is, and it has the wrapper task configured with the desired version. So when I check out a project, Intellij does not find gradle.properties (and neither can download gradle from web, as that is blocked). I then have to change the option "Use Gradle From" manually each time.
Another solution I tried is to automatically run a script when opening a module, which would run gradle wrapper with a fixed gradle version for the module, hence generating the missing wrapper files. But I find no possibility in Intellij to trigger that upon import..
It is not possible to change this setting for all projects. Please vote for this request: IDEA-215792.
Installed clean windows10(1607) and intellij idea(2020.1.2 community edition). When i create new gradle project
Invalid Gradle JDK configuration found. Open Gradle Settings
"gradle-wrapper.properties not found".
How can I fix it?
Install gradle 6.7
sdk install gradle 6.7
brew install gradle
Go to IntelliJ and set gradle version:
On File >> Settings >> Build, Execution , Deployment >> Gradle
or
Preferences >> Gradle
In Use Gradke from specific the correct location
If IDEA is set to use the Gradle wrapper (as it is in your screenshot: "Use Gradle from:" is set to "gradle-wrapper.properties"), IDEA expects the following file structure:
Gradle wrapper JAR: [project root]/gradle/wrapper/gradle-wrapper.jar
Gradle wrapper properties: [project root]/gradle/wrapper/gradle-wrapper.properties
Gradle wrapper script: [project root]/gradlew.bat
If you are missing one of these three elements, IDEA will attempt to generate the wrapper by calling the gradle wrapper task. It will do this using the Gradle JDK, which may or may not be the project SDK (File > Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JVM).
I'm not sure how it selects the version of Gradle it uses - I only have 6.8.3 installed on my machine, and I had my wrapper properties set to 7.0-rc-1, yet somehow it used 6.7.0 when generating the wrapper.
I tried various options for clearing the cache, but did not get the result.
Openjdk-14 installed by default and does not work. From site adoptopenjdk.net install OpenJDK 11 (LTS). When creating the project, I chose 11 version. Then the program suggested updating gradle to version 6 and it worked.
I ran into this problem a while ago when I upgraded to intellij 2020.* The first time I created a new project there was no problem: gradle daemon did its work and the project was created with no problems.
In my case, the project would start a new gradle daemon, and attempt to build the project, would get rejected by windows Security, and nothing would happen, so intellij goes ahead and starts another (unsuccessful) daemon. Soon, I had 20+ gradle daemon processes running on my system, all of them doing nothing.
So, it looks like intellij has messed in enabling that it places the appropriate permissions it requires for these folders that it depends on to run properly. So, you need to manually give these permissions, and then things (should) work.
The real issue here is security on your machine: either a virus checker or the security software, Windows Security on Windows 10, for example. The first time you make a project, Intellij goes and produces a number of folders that they need access to.
However, once these folders are available, for whatever, intellij doesn't make sure to give itself access.
On windows 10, in AppData, you'll find several folders required by Intellij to produce, in my case, produce gradle projects.
Try finding the various folders that Intellij has produced on your system, and give them exceptions on your virus checker and on whatever firewall/security software programs that may block access.
My IntelliJ Idea projects have been working fine until I cloned a new project from our repo and installed Gradle.
This new project runs, but running the debugger causes the following error:
I've completed the steps recommended in this similar SO question. I have also read the Gradle Daemon guide.
Some helpful information:
-Gradle does respond to command line prompts, including --profile and --status:
-The project builds and executes; the problem is only the debugger. Is this a mapping issue between IntelliJ and Gradle?
-In the Settings menu, Gradle JVM: is set to "Use Project JDK (Java version "1.8.0_211") and this program is written in Java 8. Delegate settings set to: Build and run using intelliJ IDEA. Run tests using IntelliJ IDEA. Should these change to Gradle?
-I took the advice of one of the respondents and had one of our IT guys check out my ports and firewall settings. He was unable to solve the problem and said the issue is with Gradle.
So far, nothing has worked. What should I do?
I solved this problem after some tinkering:
In (IntelliJ) File > Settings > Build, Execution, Deployment > Gradle, I changed "Use gradle 'wrapper' task configuration" to "Use local gradle distribution."
Also, notice in this screenshot that "Gradle VM options" has a custom value; this was suggested as a solution in another post. This relates to memory management, as some people speculated that the daemon was crashing because of a RAM issue. My solution appears to work regardless of whether I alter that value.
I am new to IJ IDEA and Gradle KTS.
I created the kts by hand and imported it into IJ. IDEA has generated the gradle wrapper, but I do not want this. If I delete the gradle wrapper and associated directory, IDEA prompts me to 'import changes' from gradle, which then creates the gradle wrapper again...
My question is how to prevent this behavior? ie prevent gradle wrapper generation?
I found documentation for the Wrapper task, and the option to point to a local install using distributionUrl. But that doesnt seem to prevent the generation of the gradle wrapper, only bypass the download...
Also I can not find any options in IDEA to disable this behavior.
btw I do understand the benefits of the wrapper.
Thanks.
IntelliJ IDEA EAP 2019.2
macOS 10.12.4
gradle 5.2.1
kotlin DSL 1.1.3
Disabling access to the download directory seems to work:
mkdir -p ~/.gradle/wrapper/dists && chmod -rwx ~/.gradle/wrapper/dists
Note that this prevents the wrapper to work at all (which is exactly what I want) and causes error messages, but as far as I can see it does the job and the project simply has to be configured to use the system gradle distribution after import.
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