On 19/11/2010, at 1:40 AM, Jeppe Nejsum Madsen wrote:
> On Thu, Nov 18, 2010 at 2:47 PM, Luke Taylor
> <luke.tay...@springsource.com> wrote:
>> I think this is the expected behaviour. If you read the manual chapter on
>> the Eclipse plugin, and section 28.3 in particular:
>>
>> http://gradle.org/0.9-rc-3/docs/userguide/userguide_single.html#N13583
>>
>> you'll see that the plugin will merge the content into any existing files.
>>
>> It also explains how to run a clean task first so that the content is
>> completely regenerated from scratch.
>
> I see. Should have read the docs :-)
>
> I don't quite understand the reasoning behind this though: If you have
> dependencies managed by Gradle why would you manually go an edit e.g.
> the classptah in Eclipse?
I don't understand why you'd want it either. If your code has a dependency, you
should tell Gradle about it.
I think we should get rid of the dependency merging. It is difficult to get
right, and I really don't think it is worth the effort. Here are some things it
doesn't deal with at the moment:
* A change to the version of a dependency. The old version is left in the
classpath, along with the new version. This is happens so frequently that this
problem alone pretty much renders dependency merging unusable.
* Cleaning up orphaned dependencies. When I change code so that it no longer
requires a dependency, that dependency is not removed from the eclipse
classpath. Similarly, if I change my dependencies such that a transitive
dependency is no longer required, it is not removed.
* Changes to the project dependencies. If I remove a project dependency, it is
not removed from the classpath. Even worse if I remove the project as well.
* Changes to IDE path variables.
* Moving the Gradle cache.
I'd much rather get rid of these problems by axing dependency merging, that I
would fix them.
btw, I'm talking about removing the merging of dependencies only. Gradle would
still merge the rest of the IDE configuration.
Also, using beforeConfigured { } and whenConfigured { }, you can implement the
dependency merging yourself, if you like.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
