I wonder if it’s possible to instruct the build evaluator/launcher to use different resolvers per DSL blocks in order to extend the DSL capabilities. At the moment, Gradle handles the “repositories” block with an instance of DefaultRepositoriesResolver, a similar thing happens with “dependencies” and DefaultDependenciesResolver.
My question is, is it possible to let Gradle know that I want it to use MyCustomRepositoriesResolver instead of the default one? If so, how can it be done? Same thing for the dependencies resolver and possibly all other “base” resolvers such as configuration, etc (by base I mean basic DSL blocks as delivered by a Gradle build file sans plugin declarations).
Well, here’s an hypothetical Griffon build file https://gist.github.com/aalmiray/6997782 As you can see there’s a custom repository named ‘griffonCentral’ from which standard plugins can be downloaded. Right now plugins might contain be more than just plain ‘maven-like’ dependencies so a custom repository may be needed. A griffon plugin may be one of three types:
provide runtime capabilities only
provide buildtime capabilities only, i.e, add gradle tasks to the project
both (for example a task that can create a custom artifact, plus its runtime jar companion)
Thus plugins may contain 2 jars (runtime, compile) and maybe a test jar too. Technically the ‘griffonPlugin’ node would know how to handle this type of dependency, by downloading it and adding the jars to their corresponding configuration (I wonder though, that it may be too late for this type of node to alter the build’s classpath and append new taks to the project, would it? In that case griffon plugins would need to be defined inside buildScript{} and the runtime jars will be automatically added to the dependencies{} block).
Just let me know if this sounds too crazy. What I’d like is to minimize the chances of writing a bad configuration.
Hi Andres, I think one problem you have with the given syntax is how to figure out what type of plugin you’re referring. when you declare a plugin dependency using “‘org.codehaus.griffon.plugins:griffon-miglayout:2.0.0’” how can the gradle plugin figure out what type of plugin miglayout is? one option might be, that the griffonPlugin method in the dependencies block resolves “‘org.codehaus.griffon.plugins:griffon-miglayout:2.0.0’” to a griffon specific descriptor that knows the plugin details.
One other question, why do you need plugin jars on the buildscript classpath?
Precisely. The griffonPlugin node assumes the dependency is of a particular type, say griffonPlugin, same as runtime assumes the dependency is of type jar (or pom). A griffon plugin may be a zip file with jars an additional metadata file. So really what I’m wondering is if the DSL can be extended with a custom dependency resolver that can handle dependencies of type X, where I’m in full control of what X means and how it can be handled.
