Extending DSL capabilities


(Andres Almiray) #1

Hello everyone,

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).

I wonder, if the following topic + answer is the way to go http://forums.gradle.org/gradle/topics/extending_repositories_to_accommodate_publishing_to_bintray_dsl_suggestions

Cheers, Andres


(Luke Daley) #2

Short answer: no

:slight_smile:

What do you need to do?


(Andres Almiray) #3

Aww shucks :frowning:

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.

Cheers, Andres


(René Groeschke) #4

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?

cheers, René


(Andres Almiray) #5

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.

Cheers, Andres