~/.m2/settings.xml is parsed for every project in a multi-project Gradle build

In a multi-project build ‘repositories’ clause needs to be defined for every project - either with ‘allprojects’ or via ‘init.gradle’. If the local Maven repo is defined as one of the repositories, the method ‘getLocalMavenRepository’ of ‘DefaultLocalMavenRepositoryLocator’ is called every time a new subproject is parsed. In case repositories are defined for the buildscript of subprojects as well, this method is called 2N times where N is the number of projects. Every time this method is called it parses the ‘~/.m2/settings.xml’ file and checks whether there is an override of the default repository location. Ideally should be done only once - no reason there should be N (or worse, 2N) instances of the repository object. This is true for every repository, but the initialization of the local repo is the most costly.

Thanks for the report Victor. Raised as GRADLE-3219.

Are you interested in submitting a contribution to address this? I’d start with caching the result of determining where the maven local repo is, as I suspect trying to reuse repository objects wholesale across project boundaries is going to be non trivial.

Thank you! At first I didn’t see a good way to fix that - I was under the impression that every instance of a repository is created using a different set of objects - but now I see that there’s only one instance of ‘DefaultLocalMavenRepositoryLocator’ so it can just as well cache the location. I’ll try to implement this.

Regarding what you’re saying about reusing repositories, this indeed looks like a problem and more importantly, not an implementation problem. The gradle.build syntax actually forces one to declare a repository per project (whether by adding a ‘BuildListener’ in ‘init.gradle’ or using a ‘subprojects’ clause) so this is an architectural assumption not easily changed. Theoretically speaking one could even have different repositories declarations in different subprojects.

Submitted https://github.com/gradle/gradle/pull/379

Awesome thanks. We’ll look into it after the pending 2.3 release, which is in code freeze.