Automated population of a local repository

I am currently trying to help a team with a legacy build system migrate to gradle, but one of their requirements has me stumped. They must keep their external dependency repository within the SCM. I don’t want to use a flatDir repository as that loses dependency tracking and I haven’t been able to find much information about the format that a local maven repository should take. Ideally I would like to define two seperate repository configurations: 1) mavenCentral, used just by a task that downloads all dependencies and populates the local repository 2) local repository that all other tasks use to satisfy their dependencies

Any help in setting up these configurations and tasks would be greatly appreciated (or a better approach that would simplify this overall). I’d be thrilled just to get the necessary format information for setting up a local repository.


Gradle doesn’t provide such a feature (automated population of a Maven/Ivy repository). Some options:

  • Use Gradle together with a binary repository manager (e.g. Artifactory), then export the populated repository.

  • Download the dependencies with Maven, then grab the populated local Maven repository.

That said, putting a Maven repository under version control sounds horrendous. A binary repository manager can be locked down just as much and will give much better results.

I’d be thrilled just to get the necessary format information for setting up a local repository.

Not sure what you mean by that. The whole format is determined by the dependencies hosted in the repository.

I totally agree that this is a manufactured issue and could be solved in better ways, but this is a “lesser evil” sort of thing.

I’m curious about a few more points, though. 1) Is there a way to setup the configuration(s) (say repositories) so that there is one configuration for a task and another configuration for another another task? 2) There exists functionality in the maven plugin to upload jars/poms/etc. Is there a way to access those methods for custom purposes since the gradle plugin just exposes the tasks and configurations, correct?


ad1. I don’t quite understand the question. In general, you can declare and use as many configurations as you like, and you can do so generically, say in a loop.

ad2. The plugin doesn’t provide an API other than the documented tasks and domain objects (i.e. what you would use from a build script). The new ‘maven-publish’ plugin has a revised API that offers, among other things, a separate task for generating POMs.

Let’s say this. I would like the compileJava task to resolve dependencies using mavenCentral and the compileGroovy task to resolve depdencies using mavenLocal. Is there a way to do that?

Resolving a configuration checks all of the project’s repositories, in their declared order. So you’d have to spread out the tasks over multiple projects.

Thanks for help