Как я могу импортировать один скрипт Gradle в другой?

У меня есть сложный скрипт Gradle, который включает в себя множество функций, связанных со сборкой и развертыванием ряда проектов netbeans в ряде сред.

Скрипт работает очень хорошо, но по сути он настраивается через полдюжины карт, содержащих информацию о проекте и среде.

Я хочу абстрагировать задачи в другом файле, чтобы я мог просто определить свои карты в простом файле сборки и импортировать задачи из другого файла. Таким образом, я могу использовать одни и те же основные задачи для нескольких проектов и настраивать эти проекты с помощью простого набора карт.

Может ли кто-нибудь сказать мне, как я могу импортировать один файл Gradle в другой аналогично задаче Ant? Я изучал документы Gradle до сих пор безрезультатно.

Дополнительная информация

После ответа Тома ниже я подумал, что постараюсь уточнить, что я имею в виду.

В основном у меня есть скрипт gradle, который запускает ряд подпроектов. Однако все подпроекты являются проектами Netbeans и поставляются со своими собственными сценариями сборки ant, поэтому у меня есть задачи в gradle для вызова каждого из них.

Моя проблема в том, что у меня есть некоторая конфигурация в верхней части файла, например:

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

Затем я создаю такие задачи, как:

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

У меня есть много таких фрагментов создания задач, и все они являются общими - они полностью зависят от конфигурации в списке проектов.

Итак, я хочу, чтобы это можно было поместить в отдельный скрипт и импортировать следующим образом:

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.

Итак, в этом примере tasks.gradle будет содержать весь общий код генерации задач, и он будет запускаться для проектов, определенных в главном файле build.gradle. Таким образом, tasks.gradle - это файл, который может использоваться всеми большими проектами, состоящими из ряда подпроектов с файлами сборки муравьев Netbeans.

В версии 0.9 есть новая функция. Вы можете использовать apply from: 'other.gradle'команду.

Прочтите мой вопрос о том же по адресу: Есть ли способ разделить / выделить общие части сборки Gradle

Ответ на вопрос оказался в системе плагинов, где вы можете добавить желаемую функциональность в набор плагинов, которые могут быть хорошими файлами, расположенными в каталоге buildSrc/src/main/groovy. Плагины также могут быть объединены как Jar, хотя я этого не пробовал.

Подробности здесь: Пользовательские плагины

Что ж, трудно сказать, что вам лучше всего подходит, не просматривая файл сборки.

Я мог бы предположить, что настройка вашей среды как многопроектной сборки должна предоставить вам абстракцию, которую вы ищете.

В корне вашего проекта build.gradleвы определяете все, что касается вашего домена, а также то, что применяется ко всем вашим подпроектам:

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

Корневой каталог проекта также может содержать gradle.propertiesфайл, в котором вы определяете свойства, используемые вашими проектами:

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

Затем в дополнительном файле из корня вашего проекта с именем settings.gradleвы фактически указываете на свои подпроекты:

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

Каждый каталог подпроекта содержит build.gradleфайл, содержащий только материалы, относящиеся к подпроекту.

Независимо от того, вызываете ли вы gradleиз корня проекта или каталога подпроекта, gradle автоматически рассмотрит все ваши определения, сделанные в различных файлах.

Также обратите внимание, что никакая задача компиляции не будет выполняться для вашего корня проекта, пока вы не загружаете какой-либо плагин помимо плагина по умолчанию на корневом уровне.