This problem can reproduced either by calling the tooling API or running the gradle eclipse task.

I'll attach a small sample project which is derived from the gradle build scripts of Grails core.
Grails core uses the idiom that causes problems in a number of places, so in order for Grails-core
projects to work well inside of Eclipse using the tooling API, this bug is a blocker.

The following build.gradle file shows the idiom:

apply plugin: 'java'
apply plugin: 'eclipse'

repositories {
	mavenCentral()
}

configurations {
    special.extendsFrom compile
}

dependencies {
   special "junit:junit:4.8"
   compile "commons-lang:commons-lang:2.4"
}

sourceSets {
	main {
		compileClasspath = files(configurations.special)
	}
}

Salient features:

• The 'special' configuration is defined as 'compile' configuration plus one extra jar.
• compileClassPath of main sourceset is defined to use 'special' dependencies rather than 'compile'
  dependencies (so compile + one special jar).

When a build a project that has source code referring to classes in both jars, using 'gradle assemble' it compiles without problems.

When we import such a project in Eclipse (either using 'gradle eclipse' plugin or STS tool support based on tooling
API, the classpath container will only contain 'compile' dependencies. The 'special' dependencies are not included.
This results in compilation problems in the IDE.