On Jun 2, 2010, at 12:19 PM, Hans Dockter wrote: > > > On Tue, Jun 1, 2010 at 2:25 AM, Jason Porter <[email protected]> wrote: > On Mon, May 31, 2010 at 17:09, Adam Murdoch <[email protected]> wrote: > > > > > > On 29/05/10 3:57 AM, Steve Appling wrote: > >> > >> We would really like to resolve the issues related to circular > >> dependencies (GRADLE-914 in particular) sometime soon. I know this is > >> marked for 0.9, but so are 91 other issues. Is this something that anyone > >> is planning on addressing in the short term (within the next couple of > >> weeks)? If not, does anyone understand the underlying problem enough to > >> point me in the right direction? > >> > > > > I know of 2 problems. There may be more, but this is as far as I got: > > > > 1. The compile configuration is now transitive by default (for good or bad). > > :( That blows. Should be non transitive, if you need it on your > compile path, put it there. This way I know exact what I need to > compile, not some third level transitive dependency that happens to be > there. Major sad face on this one. > > Unfortunately non-transitive compile does not work out. The idea behind this > is good for the very reasons you mentioned above. But it has serious issues. > > - Groovyc needs the transitive dependencies for compiling in any case > - Javac also needs the transitive dependencies in some circumstances to > compile. Even if your code only accesses first level dependencies. > > Therefore we had to change that and we need to implement the idea behind this > in a different way. > > - Hans >
That's not clear to me, Hans. Why would javac ever need more than the first level dependencies? I would also like the build to explicitly declare everything needed to compile. That being said, this seems like a separate issue from the particular circular dependency problem I am encountering. The problem is resolving a runtime dependency loop for some functional tests. This really does need to be transitive, but currently results in an Ivy error that it can't resolve the jar that is the artifact from one of our sub-projects that is involved in the loop.
