如何在gradle插件中添加自定义依赖关系处理程序？

Question

I would like to provide users of my gradle plugin a simple way to add all necessary dependencies. something like gradleApi() or localGroovy() .

I found out that both - gradleApi and localGroovy - are defined in DependencyHandler and implemented in DefaultDependencyHandler . Can i provide a custom implementation of Dependencyhandler which extends DefaultDependencyHandler in my plugin? Or is there even a simplier way to achieve what i want?

thx in advance.

Answer 1

One solution is to have the plugin install an extra method on the dependencies container:

def jarDir = ...

project.dependencies.ext.pluginDeps = { 
    project.fileTree(jarDir) // filter file tree if necessary 
}

Users can then do:

dependencies {
    compile pluginDeps()
}

Extra properties/methods are normally meant to be used by build scripts only (because they aren't backed by a model that can be discovered and reasoned about), but in this particular case (and as of Gradle 2.1) I can't think of a clearly better solution.

PS: Keep in mind that for file (rather than repository) based dependencies, no version conflict resolution will occur.

Answer 2

See if this helps to some extent. Let's say you create a custom plugin / class and consume it's artifact that in Gradle (within GRADLE_HOME/init.d/common.gradle file level).

Custom plugin project's java/groovy file will look like

// Your custom plugin class file will look like
// Your custom plugin's source code will reside at: com.mycustom.plugin.gradle under src/main/java folder tree. 
package com.mycustom.plugin.gradle
import org.gradle.api.*
import org.gradle.api.file.*

import java.io.File;

public class myCustomFileUtil {
    /**
     * Default constructor
     */
   public myCustomFileUtil() {
   }

   /**
    * Read file returning list of lines. Double slash (//) at start of line
    * defines a comment.
    * @param fileName File to read.
    * @return List of lines.
    */
    public static List readIntoList( String fileName ) {
      def fname = new File( fileName )
        def listFinal = []
        def listLines = fname.readLines()
        listLines.each { it ->
            def str = it.trim();
            if( str.length() > 0 ) {
                if( ! str.startsWith( "//" ) ) listFinal.add( str );
            }
      }
        return listFinal
    }
}

In build.gradle

// The following funcationality is coming from a custom plugin that you'll write which will read a text file and create a list.
// It'll also ignore any lines that start with "//"
import com.mycustom.plugin.gradle.myCustomFileUtil

sourceSets {

   //if you have any
   //main
   //test
   //acceptanceTest
   //etc

}

// Read dependency lists from external files
List depListCompile = myCustomFileUtil.readIntoList( "$projectDir/dep-compile.txt" )
List depListTest = myCustomFileUtil.readIntoList( "$projectDir/dep-testArtifacts.txt" )
List depListWar = myCustomFileUtil.readIntoList( "$projectDir/dep-war.txt" )
List depListJibx = myCustomFileUtil.readIntoList( "$projectDir/dep-jibx.txt" )
List depListSomeOperationINeed = myCustomFileUtil.readIntoList( "$projectDir/dep-someoperationineed.txt" )


// Define dependencies
dependencies {
   // Compilation
   compile  depListCompile

   // If dependencies already exist on the local folder / in some workspace
   compile  fileTree(srcDir: "somefolder/whichcontain/myjar", include: "*.jar")
   compile  fileTree(srcDir: "/path/xx/yy/somefolder/whichcontain/myotherartifacts", include: "*.[zw]*")
   compile  fileTree(srcDir: "C:/zzz/somefolder/whichcontain", include: "myotherartifacts/*.[pj]*")

   // Unit Tests
   testCompile depListTest

   // Acceptance tests
   // Everything from compile and testCompile targets
   acceptanceTestCompile configurations.compile
   acceptanceTestCompile configurations.testCompile

   // Output of compiling "main" files
   acceptanceTestCompile sourceSets.main.output

   // Additional dependencies from war and others
   acceptanceTestCompile depListTest, depListWar

   // All configuration files
   acceptanceTestRuntime files( 'conf' )
}
// ... and more code here to do other operations

In dep-compile.txt you can have entries like

com.mycompany.project:oneofmycompanyartifact1:1.1.1
com.mycompany.project:oneofmycompanyartifact2:1.0.1@zip

httpunit:httpunit:1.6
jibx:jibx-bind:0.10.3.3
jibx:jibx-extras:0.10.3.3
jibx:jibx-run:0.10.3.3

cactus:cactus:1.7.2
selenium:selenium:0.9.2

Similarly, in dep-testArtifacts.txt, you can have the following entries (and create similar dep-XXXX files per Gradle phases/functionality you want: compile, test, war, doingSomeOperation etc).

cactus:cactus:1.7.2
jackson-all:jackson-all:1.9.9
jibx:jibx-bind:0.10.3.3
jibx:jibx-extras:0.10.3.3
jibx:jibx-run:0.10.3.3
//junit:junit:4.10
junit:junit:4.11
mockito-all:mockito-all:1.9.5

Answer 3

I found another way to do this. You can rely on the convention mechanism to do it. First define a convention class:

class CustomDepsPluginConvention {
    // here you can return anything which configuration methods in the
    // `dependencies` block would accept, e.g. a string or a map
    fun customDependency(): Map<String, String> {
        return mapOf(
            "group" to "com.whatever",
            "name" to "whatever",
            "version" to "1.2.3"
        )
    }
}

Then you add this convention object to the project in the plugin apply() method:

open class CustomDepsPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        // the identifier of the convention object does not matter,
        // as long as it is unique
        project.convention.plugins["customDeps"] = CustomDepsPluginConvention()
    }
}

After you apply this plugin, the convention object will be added to the project object, exposing all its methods and properties on the project object and thus making them available directly in the build script:

apply plugin: CustomDepsPlugin

dependencies {
    compile customDependency()
}

This approach is arguably cleaner; the only potential downside of it is that convention objects are kind of "deprecated" and are not recommended to be used. Also, it may cause issues with the Kotlin DSL (as far as I remember, convention objects are not really supported by Kotlin DSL); if you want to support Kotlin DSL, though, you can expose these dependency-generating functions as importable top-level functions and import them to your build script.