Eclipse and Gradle classpath out of sync: cannot be resolved to a type

Question

We are having a frustrating problem with our Eclipse workspace. Here is a high-level example of what is happening:

ProjectA
-- src/main/java/...
-- build.gradle

ProjectB
-- src/main/java/...
-- build.gradle

After running gradle eclipse and importing the projects into Eclipse, we occasionally will get 'MyType cannot be resolved to a type' even though the following are true:

• Our projects have the Gradle library container on their classpath
• The projects have the correct workspace projects within their Gradle container
• Things like CTRL + Click work from types that are showing up with red underline (i.e. compile error) meaning Eclipse knows exactly how to get to those types, but the compiler can't find them
• Command-line Gradle builds work as expected

This is happening throughout the team and we cannot figure out why Eclipse keeps going out of sync and cannot compile from time to time. What usually fixes the problem is a combination of:

• Project > Clean in Eclipse
• Gradle cleanEclipse or gradle eclipse
• Reimporting the projects
• etc

Other notes:

• Using Gradle version 2.2.1
• Happens in both Eclipse Luna and Eclipse Mars
• Using JDK 8

Has anyone else had these types of compile issues in Eclipse with Gradle projects?

Answer 1

One source of such problems can be letting Gradle generate the Eclipse project metadata/setup files (what you get by running gradle eclipse). I know that the Maven and Gradle teams really want their tool (Maven or Gradle) to generate that stuff, but they notoriously do a less-than-ideal job of it. For example, the last time I used Gradle it configured the .classpath to use a hard-coded JRE library path instead of the preferred Execution Environment. That kind of poor job of generating files makes for developer headaches.

Instead, the Eclipse recommendation is to manually configure your projects (for the most part), only letting Gradle manage its Classpath Container, then checking in the Eclipse .project, .classpath, and .settings files/folders in to your SCM (svn, git, etc.). That way, the process of checking out a project into a workspace is automatic and does not require running gradle eclipse or mvn eclipse:eclipse all the time.

That's the way that Eclipse projects were originally designed and intended to be managed, and it works very well. I've worked with setups like that on very large projects (100+ separate projects in Eclipse and dozens of developers). It also cuts down on the number of steps to go from zero to running app.

This is one of those philosophical differences between Maven/Gradle and Eclipse; when it comes down to it, IMO, the IDE should manage it's stuff and the build/dependency tool should just stay out of the way.

Try manually getting things just right in your project configuration and then checking in those files - see if it doesn't relieve the headaches your team faces in this area.