Hi Luke Thanks for pointing this out. Proved a little tricky to diagnose, as this problem doesn't exist in either M6 or HEAD.
The problem is that we're not using our custom POM parsing code for local repositories: ivy default behaviour is to try to resolve javadoc and source jars for every module, and this lookup is not restricted to the same resolver. So not finding javadoc/source jars locally, ivy proceeds to search all available resolvers for these. This all happens down in dependency-resolver land, below our caching layer. This was fixed in a recent refactoring that consolidated our local and remote caches somewhat: they now share the same descriptor parsing infrastructure, including our custom no-source-or-javadoc-downloading pom parser. I'm sure people are using mavenLocal as a caching layer, and we should discourage this. There's not much point now that we can reuse artifacts from maven transparently. cheers Daz On 6 January 2012 05:33, Luke Daley <[email protected]> wrote: > Hi all, > > While investigating a report of a performance regression with m7, I > stumbled upon some behaviour I can't explain. > > I've been playing with this project: https://github.com/chochos/jalarms > > (to run it, remove the uploadPublished block in the root build.gradle) > > This build uses the mavenLocal() repo. I noticed that dependency > resolution is considerably slower when this is one of the repos. I did some > digging and found that it looks like when mavenLocal() is in play we don't > uses our cache as well, if at all. > > You can see this by running: > > ./gradlew jalarms-channels:classes -debug -no-daemon | grep GET > > With mavenLocal() in and with it out. > > Can anyone explain what's going on here? > > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
