Feb 9, 2015
Feb 17, 2015 (Retired)
Andrew Grosner (agrosner)
Alex Rouse (alexrrouse)
Source code



A powerful dependency management solution for Android/Java-based gradle build environments. It drastically reduces the complexity of build.gradle files while providing powerful and flexible dependency resolution on top of normal Gradle. It handles linking remote sources for you automatically.


Including in your project

Add the following block to your buildscript.repositories{} block in the project-level build.gradle

buildscript {
    repositories {
        maven { url "" }
    dependencies {
        classpath 'com.raizlabs:Griddle:1.0.3'


// this should come after '' or '
apply plugin: 'com.raizlabs.griddle'

Optional Properties

This library uses gradle properties to determine where to search for the dependencies. For example:

griddle_default_group: The group to resolve dependencies without a specified artifact equivalent when simply specifying a name for the dependency.

griddle_default_library_directory: The default directory to resolve local submodules in. Default is ":Libraries"

griddle_default_library_extension: The default extension on dependencies when simply specifying a name for the dependency and the local version is not found. Default is empty. You can specify something like @aar or @jar if needed.

Add these variables to your global ~/.gradle/ file, or in project-level file.


  1. mod() + nsMod()
  2. jar()

mod + nsMod

The mod() and nsMod() functions are a wrapper around a compile statement and provides the following:

  1. Automatic determination if there is a local or remote dependency
  2. only mod() Automatically links a sources.jar to a remote dependency
  3. Custom artifact notation to "swizzle" in multiple dependencies from the same repo


mod ''

mod '{DBFlow-Core, DBFlow}:1.4.2'

mod 'Parser'

mod '{Parser, :Parser:Parser}:1.2.0'

Remote vs. Local

Many times in projects we have a list of dependencies that we utilize and they either specify a remote or local dependency. To simplify this process and enable us to dynamically switch between local and remote as needed, this plugin provides you with a very simple and powerful way such that you will never need to modify your projects build.gradle.

Dependency resolution for local vs. remote is determined if a project exists in the settings.gradle. Aiding in that aspect is the griddle_default_library_directory that will help specify its location when we omit the directory prefix in a mod() or nsMod() statement.

You can specify different names for local vs. remote by specifying the following:

mod 'artifactId:{{moduleName, localModuleName}}:version'

mod 'artifactId:{{moduleName, localModuleName}, {anotherModuleName, anotherLocalName}}:version'

Linking Sources

Surprisingly enough, the standard compile statement in Gradle does not enable attaching sources to the remote dependency easily. Also, to note, we do not want to have to manually attach sources every time we update a dependency and ensure that those sources are the correct one.

By using the mod() function, sources will automatically get attached. Note: not all dependencies have sources, so if it fails to discover a sources.jar use nsMod() (no-source module) instead.

Custom Artifact Notation for build.gradle dependency crushing


For multiple dependencies coming from the same repo that all have to share the same version, previously we had to do something like this:

dependencies {
  compile ''
  compile ''
  compile ''
  compile ''

Every time we want to update, we have to painstakingly change each one. Using the mod() or nsMod() (for this example), we can move this declaration to one line.

dependencies {
  nsMod '{play-services-maps, play-services-location, play-services-plus, play-services-fitness}:6.5.87'
Custom Notation Features

Using the mod or nsMod in this format: mod 'groupId:artifactName:artifactVersion' you can:

  1. Place {} around the artifactName and add more similar artifacts separated by commas. If you place one or more of the comma-separated items in {}, you can specify remote vs local such like:
mod '{BaseUtils, {WebServiceManager, :WebServiceManager:WebServiceManager}}:1.0.0'
  1. If (1) is used, you can place {} around the artifactVersion and specify a per-dependency version. Note the length of comma-separated artifactNames must match the versions specified.
  2. Add a configuration (such as compileDebug) name to the end of the function:
mod 'groupId:artifactName:artifactVersion', 'compileDebug'

Note any artifact specified this way will automatically utilize the next feature of this library. If there is a local version available in the settings.gradle by combining these properties:

Specifying in this format: mod 'artifactName':

  1. Utilizes the griddle_default_group if the local version is missing
  2. Utilizes griddle_default_library_directory to find the local version of this repo
  3. Uses the griddle_default_library_extension if local version is missing by appending it to create the
compile 'groupId:artifactName:artifactVersion{extension}'


For specifying a jar dependency, we usually specify it this way:

dependencies {
  compile files('libs/android-support-v4.jar', 'libs/http-master-1.0.6.jar')

For a much cleaner approach, with this plugin we can use:

dependencies {
  jar 'android-support-v4'
  jar 'http-master-1.0.6'

The jar() method will automatically append libs and .jar to the dependency to clean up the look of the file. If you need all jars, use the method jars() to mimic the compile fileTree("libs", include: "*.jar")


agrosner (@agrosner)