Can repositories be tied to a specific configuration

I’ve run into a few scenarios where I need/want to tie some configurations to different set of repositories, and not necessarily the pool of all repositories. Is it currently possible? In Ivy-land I’d make references to different repos and and use them exactly when I need them, without needing to put them in the same resolve chain.

Here’s the use case, for the compile configuration I want to use an internal Artifactory with a curated repositories of 3rd party libraries. I’ll set it up via project.repositories. I let buildscript.repositories point to a maven central proxy, so that plugins have complete access to what ever makes the most sense to build the code. Then someone goes on to apply plugin checkstyle, which creates a new configuration in the project (called checkstyle) and needs to resolve. The plugin comes from buildscript.repositories but parts of it are coming from the repository that I had defined for my core-code compile configuration. This forces me to build-time dependencies in my repo. I really don’t want to mix this use cases.

I think there’s a general need for tying a configuration to a repositories, e.g. I want to bring in the latest artifactory plugin, but to do that I have to add their repo, which consequently means I’m bringing it in for all other plugins, which will effect behavior based on what they have in their repo.

(In the first case, the plugin is coming from Gradle itself which lacks the checkstyle dependency to run the plugin, but that’s another matter.)

No, this isn’t currently possible (except that different subprojects can have different repositories). Similar ideas have been discussed a few times, and I assume that future Gradle versions will provide more control over which repositories are searched for a particular dependency. Note that some of these goals can also be achieved by configuring the repository manager (filters, virtual repositories), which may be easier to manage.

Using a repository manager is a necessary component, but it solves a different problem set. I look forward to seeing progress on this front in the future.

Thanks for the response.