Yes, I understand that. This is not about compilation failing but validation. Errors are shown in the console and validation is not complete. Depending on what Eclipse does, there is a risk of it not continuing the compilation of other projects because of this. Fortunately for us, that is not what is going on in this case.
I wish Eclipse plugins would stop pretending that they are the source of truth, when in reality every real project has a build system that already knows all the dependencies.
I agree 100%. Problem is that we are not in control of those.
You’ll actually have to exclude the binary dependencies that are already on your classpath, but which should be provided by the container instead. Something like eclipse.classpath.minusConfigurations << configurations.gwt
I am aware of this too. We are actually quite thorough on normalizing dependencies presently (that will go backwards with Buildship) as projects do export their dependencies and only add those that they did not import. We created a Gradle plugin that does this for us. This approach greatly helps with Eclipse performance and memory consumption, among other things. Duplicate classpath entries can cause failures - but, fortunately for us, in this GWT case, they do not matter. Furthermore, both the Gradle’s vision of the classpath and the container one are, actually, pointing to the exact same set of files (not just equal) as we auto-configure Eclipse container to point to them.