Hi, maybe I'm missing something, but I thought that's exactly the point of 'eclipseCleanClasspath'. I always let 'eclipseClasspath' depend on 'eclipseCleanClasspath' to avoid that problem. If you remove the merging functionality the clean task becomes somewhat obsolete, doesn't it?
Martin On Jan 10, 2011 10:29 PM, "Adam Murdoch" <[email protected]> wrote: Hi, At the moment the 'eclipse' and 'idea' plugins attempt to merge the project's dependencies (as defined in the build script) with the existing IDE classpath defined in the .classpath/.iml file. However, the implementation doesn't really work, so that you end up with old dependencies in the IDE classpath as your project dependencies change over time. While it is possible to fix this, it doesn't, to me, seem worth the effort. Instead, I'd like to remove the merging. After this change, the 'ideaModule' or 'eclipseClasspath' tasks will ignore the existing classpath and replace it with the dependencies defined in the build script. The result will be a much more accurate IDE classpath, at the cost of losing any manual configuration you might have made to that classpath. Note that I'm talking about the classpath only - the merging of other configuration in the ide files will continue to work. Anyone have a good reason to keep (and fix) the dependency merging? -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
