IntelliJ IDEA and Gradle - Cannot be applied to '(groovy.lang.Closure)'

Question

I have a Gradle file which, whenever I load open it in IntelliJ IDEA 14.1.5, shows IDE errors for the entire file. Namely all the errors seem to be either:

java.

Answer 1

For me, after trying out all this answers without result, changing the Java SDK of the project did the trick, I was on 1.8 and changed it to the newest one, but still a project level language of 8.

Hope this helps!

Answer 2

Happened to me recently on windows. I tried all of the above but it didn't work.

What i did:

1 - I had JAVA_HOME environment variable already set. So IDEA picked that as project SDK and these warnings showed up.

2 - So, i removed the default JAVA_HOME from project SDK and manually added jdk path. Restarted and all warnings were gone.

Maybe it will help someone. Thanks.

Answer 3

For the first part of the question: group is a property, so there must be an assignment, not a function call. The right code is:

group = 'com.me.blah'

Answer 4

I've noticed this often. When creating a new project and using the 'Gradle' template, IntelliJ seems to get it all wrong. So what I've resorted to doing is after creating a new project, delete the .idea and .iml files and re-open the project directly from the Gradle file. IntelliJ seems to better understand what is going on in this case.

Answer 5

For anyone looking for a similar fix, this boiled down to the type of the module. My module was defined in my .iml file as

type="WEB_MODULE"

I created a new Gradle module and pasted in the same contents, deleted the original, renamed the new module to have the same name as the old one, and everything worked fine. When I diffed the results the only change was that the .iml file now said:

type="JAVA_MODULE"

So there's the answer, seemingly. Change your module from "web" to "java".

Answer 6

I found this suggestion in the IDEA bug tracker(IDEA-142683):

Workaround:
One can add a comment such as
//noinspection GroovyAssignabilityCheck
to suppress the warning, but this should not be necessary as these are standard every day Gradle usages.

This issue was recently updated and is marked fixed, ready for release with version 2016.2 release.