¿Cómo puedo importar un script de Gradle a otro?

Question

Tengo una secuencia de comandos gradle complejo que envuelve una gran cantidad de funcionalidad en torno a la construcción y la implementación de una serie de proyectos netbeans en una serie de entornos.

La secuencia de comandos funciona muy bien, pero en esencia está todo configurado a través de media docena de mapas que contienen información del proyecto y del entorno.

Quiero resumir las tareas en otro archivo, de modo que simplemente pueda definir mis mapas en un archivo de compilación simple e importar las tareas desde el otro archivo. De esta manera, puedo usar las mismas tareas centrales para una serie de proyectos y configurar esos proyectos con un conjunto simple de mapas.

¿Alguien puede decirme cómo puedo importar un archivo gradle a otro, de manera similar a la tarea de Ant? He rastreado los documentos de Gradle en vano hasta el momento.

Información adicional

Después de la respuesta de Tom continuación, pensé que iba a tratar y aclarar exactamente lo que quiero decir.

Básicamente tengo un script de gradle que ejecuta una serie de subproyectos. Sin embargo, los subproyectos son todos proyectos de Netbeans, y vienen con sus propios scripts de compilación ant, por lo que tengo tareas en gradle para llamar a cada uno de estos.

Mi problema es que tengo alguna disposición en la parte superior del archivo, tales como:

projects = [ 
    [name:"MySubproject1", shortname: "sub1", env:"mainEnv", cvs_module="mod1"], 
    [name:"MySubproject2", shortname: "sub2", env:"altEnv", cvs_module="mod2"] 
] 

entonces generar tareas tales como:

projects.each({ 
    task "checkout_$it.shortname" << { 
     // Code to for example check module out from cvs using config from 'it'. 
    } 
}) 

que tienen muchos de este tipo de los fragmentos de generación de tareas, y todos son genéricos; dependen completamente de la configuración en la lista de proyectos.

Así que lo que quiero es una manera de poner esto en una secuencia de comandos independiente e importarlo en el siguiente tipo de camino:

projects = [ 
    [name:"MySubproject1", shortname: "sub1", env:"mainEnv", cvs_module="mod1"], 
    [name:"MySubproject2", shortname: "sub2", env:"altEnv", cvs_module="mod2"] 
] 

import("tasks.gradle") // This will import and run the script so that all tasks are generated for the projects given above. 

lo tanto, en este ejemplo, tasks.gradle tendrá toda la generación de tareas genérica código en, y se ejecutará para los proyectos definidos en el archivo build.gradle principal. De esta forma, tasks.gradle es un archivo que puede ser utilizado por todos los proyectos grandes que consisten en una serie de subproyectos con archivos de compilación Netbeans.

Answer 1

La respuesta a la pregunta resultó ser en el sistema de plugins, donde se puede añadir la funcionalidad deseada en un conjunto de plugins que pueden ser archivos maravilloso ubicadas en el directorio buildSrc/src/main/groovy. Los complementos también se pueden agrupar como un Jar, aunque no lo he intentado.

Detalles aquí: Custom Plugins

Answer 2

Bueno, es difícil saber qué le sirve mejor sin ver realmente su archivo de compilación.

Podría suponer que reforzar su entorno como creación de proyectos múltiples debería proporcionarle la abstracción que está buscando.

En la raíz de su proyecto build.gradle se define toda su materia específica de dominio, así como las cosas que se aplican a todos sus subproyectos: directorio raíz

repositories { 
    add(new org.apache.ivy.plugins.resolver.FileSystemResolver()) { 
     name = 'destRepo' 
     addIvyPattern(file(project.properties['repo.dest.dir']).absolutePath + '/[organisation]/[module]/ivys/ivy(-[revision]).xml') 
     addArtifactPattern(file(project.properties['repo.dest.dir']).absolutePath + '/[organisation]/[module]/[type]s/[artifact](-[revision]).[ext]') 
     descriptor = 'optional' 
     checkmodified = true 
    } 
    ... 
} 
... 
subprojects { 
    sourceCompatibility = 1.5 
    targetCompatibility = 1.5 
    group = 'my.group' 
    version = '1.0' 
    uploadArchives { 
     uploadDescriptor = true 
     repositories { 
      add rootProject.repositories.destRepo 
     } 
    } 
    apply{ type my.group.gradle.api.plugins.MyPlugin } 
    ... 
} 

dependsOnChildren() 

El proyecto también podría contener un archivo gradle.properties donde se define propiedades utilizadas por sus proyectos:

buildDirName=staging 
repo.dest.dir=/var/repo 
... 

Luego, en un archivo adicional de su raíz del proyecto llamado settings.gradle que en realidad apuntan a sus subproyectos:

include 'my-first-component', 
     'my-second-component' 
... 
project(':my-first-component').projectDir = new File(rootDir, 'path/to/first/component') 
project(':my-second-component').projectDir = new File(rootDir, 'path/to/second/component') 
... 

Cada directorio sub-proyecto contiene un archivo que contiene build.gradle solamente la materia específica sub-proyecto.

No importa si invoca gradle desde el directorio raíz de su proyecto o subproyecto, gradle considerará automáticamente todas sus definiciones en los diversos archivos.

También tenga en cuenta que no se ejecutará ninguna tarea de compilación para la raíz del proyecto siempre que no cargue ningún complemento más allá del complemento predeterminado en el nivel raíz.

Answer 3

Hay una nueva característica en 0.9. Puede usar el comando apply from: 'other.gradle'.

leer mi pregunta sobre lo mismo en: Is there a way to split/factor out common parts of Gradle build