Just tried out the new milestone-6 which Luke Daley pointed me to on Twitter. For at least one of our projects it keeps on going with the dependency resolution. It seems like it is continuously looping in the DependencyGraphBuilder. It might be that the dependencies we have together make up a cykel, which then makes it go round in circles.
Zip contains 2 log files, one from milestone-3 and one from milestone-6. In both cases I simply executed ‘gradle :ws:dependencies -d’, where ‘ws’ is obviously the name of one project in a multi-project build.
I’ve been experiencing that same thing with 1.0m6.
I have a project with extensive dependency hierarchy that runs fine on v.0.9.2 but grinds to a halt on 1.0m6. (speed of 1.0m6 on smaller projects is impressive though) After few iterations of cleaning the cache between runs it seems to kind of slow down usually around same place (observing the download log statements).
Is there some good way of being able to examine what dependencies are giving m6 this grief? Not so sure that a dependency report would report to me which dependencies seem to problematic.
I’m going through a local nexus instance that has all necessary external maven repos proxied.
The basic problem is that the new algorithm considers every path through the dependency graph. This is because each edge in the graph can introduce excludes that affect the result deeper in the graph, and also to give accurate results when a conflict includes/excludes a particular subgraph. This approach doesn’t scale as the graph gets deeper.
So, we will tweak it to merge the paths. In particular, if there is a single path to a module version that does not exclude anything, we can ignore all the other incoming paths to that module version. And when this isn’t the case, we can use the intersection of the exclude rules for all incoming paths and have a single outgoing path (these two cases are really the same thing).