For anyone following along, much of this is useful outside of the context of
authoring a plugin. For instance, our build script injects a convention
object for the purpose of defining new "system wide" properties and
methods. By system wide I mean across all the projects in the build. Many
of these usages could be handled by defining a property on the root project,
but using the convention pulls all these items together into a single
place. What we actually do is figure out a lot about the state of the build
in settings.gradle and then it creates and injects a convention object
before any projects are even loaded. This has worked very well for us.
Another thing you can do using convention objects is define methods. These
methods can then "extend" the Gradle DSL which you can then use to make your
own special needs become declarative instead of imperative. (Anyone who has
attended one of my Gradle talks in Atlanta will probably recognize this
language, haha.) For instance, our project uses native libraries along with
Java code. So, I put a "def nativeLibs(Closure conf)" method in the
convention object. I then defined a NativeLibs class that the closure
delegates to. This allows the build scripts to do:
nativeLibs {
bin 'group:artifact:version'
}
There is then a task defined in the root build that uses the information
that has been gathered into the NativeLibs instance that is in the
convention to pull down the appropriate native library based on the OS for
which we are building and put that library in the 'bin' directory. I think
this is a very powerful idea that allows Gradle to be more than just a build
tool and instead makes it a tool for creating custom build systems (in the
case where you need this level of complexity).
Much of this is doable using MOP (meta object programming) in Groovy, but
that technique has some limitations and is not nearly as easy to use as
Gradle's convention idea. It's a pretty powerful idea (but I agree with
Adam that it's experimental as it does have some issues).
--
John Murph
Automated Logic Research Team
