Hi, having worked for several months with gradle and IntelliJ, it was a pain to find compatible versions. We found that gradle1.10 works with IntelliJ 13.1.2, but not 13.1.3 or 13.1.4. gradle 1.12 on the other hand works with intellij 13.1.4, but not with 13.1.2 for Java projects. When trying an invalid combination, the gradle refresh function in IntelliJ would fail with one Exception or another (all ticketed already).
So for several teams working with some shared projects, all teams have to synchronize IntelliJ and gradle wrapper versions, or teams have to unify their installed gradle versions, both alternatives are messy. I don’t even know how it is for other IDEs. I know there is a gradle idea plugin, but this is no real alternative.
While none of this is strictly caused by gradle, I believe gradle could make a better effort in offering a unified API for IDEs to use to create a representation of a project. I think about a standard gradle task that produces some JSON which represents a declarative IDE view of a project. This could be unit-tested by gradle before releasing new gradle versions, such that the same project will offer the same declarative project structure over many gradle versions, and IDEs can rely on that to produce a stable user experience.
This requires obviously the assumption of a reasonable buildfile, meaning sourcesets and configurations do not get changed by tasks or other logic, but that assumption is the same as now. The outout format could even be aligned with Maven, possibly.
Ideally that API would make specific gradle plugins for eclipse, idea and other IDE plugins unnecessary, leaving it to the IDEs to define imports. This should be less effort to maintain than the current situation of having gradle plugins for each IDE, and each IDE independently defining imports, both sides having to cope with different versions the each tool.
Other issues e.g. we faced are that dependencies declared with testCompile would not allow compiling tests, and that classpath resources from non-standard sourcesets would not be available when launching programs from IntelliJ.
AGain, I understand these are not Gradle issues, but the Gradle ecosystem can only benefit from a good IDE integration, and the idea gradle plugin is only a crutch in that regard.
Gradle idea plugin is intended to be this common denominator that works across various IntelliJ versions. As such it has some limitation (for example it does not know target IJ version so it is generating files working in IJ12+ ignoring some features added later). It would be interesting to know why it is not a real alternative for you.
IntelliJ integration integrates through Gradle’s Tooling API that expose IdeaProject model - basically the same information that is used by Gradle idea plugin. It does some other things on top of that to provide better integration. Some of them depend on internal implementation and that’s why they break from time to time. Long term we are working on improvements in this area but as you can see it is a work in progress.
Unified IDE model: in some sense we are aiming at that. We will be introducing a new model to describe JVM projects and IDE plugins will be based on that. Because each IDE uses a different model and one size doesn’t fit all here. Again we’re not there yet but it is underway.
We understand that this is a serious issue and we have gradle IDE plugins and Tooling API covered with unit tests and more importantly with integration tests. Of course there is always a space for improvements: in this case the biggest one would be to really test latest Gradle builds against latest IDE releases (potentially nightlies/promoted builds/releases). I believe IDE vendors have an interest in their test suites testing their IDE builds against multiple Gradle versions (including recent builds/RCs).
So one problem is that team members will still use IntelliJ gradle integrations, no matter what they’re told, so the team has incosistent setups. Also it is rather common for us to have to refresh the project after changes to the gradle file, and again team members are more likely to hit the refresh button than to use the gradle idea task. It is also not very convenient to run gradle tasks from within IntelliJ, because all tasks are listed in a flat list making it a bit hard to find individual tasks. This seems like mere bickering, but the effect is that team members will still try to use other setups, causing problems. The integration with gradle is to me mostly an usability problem. I can use the shell without problems, but in a large mixed team it becomes harder to persuade people to use the command line when they are used to clicking prominent buttons on the screen. In general it is confusing for the team to understand that there are two very different way of achieving a project refresh, with results being seeming unpredictably different from each other. The latest problem I have detected is with EAP14 (http://youtrack.jetbrains.com/issue/IDEA-128966) where in order to run a file from a non-standard gradle source-set, resources were missing. This made me think that there is a lot of duplicate effort in trying to use the gradle tooling API to build an IntelliJ model. Maybe an alternative would be to provide a jar that sits on top of the gradle tooling API and is consumed by both the gradle idea plugin and IntelliJ.