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

Question

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

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

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

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

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

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

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

В основном у меня есть скрипт 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.

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

677 3

java gradle groovy build

3 ответов:

Comments

Ничего не найдено.

Andrey Adamovich · Accepted Answer · 2017-05-23 15:34:12

есть новая функция в 0.9. Вы можете использовать .

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

Anthony Roy · Accepted Answer · 2013-06-12 22:25:45

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

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

Tom · Accepted Answer · 2010-02-19 02:19:01

ну, трудно сказать, что вы лучшие, не видя вашего файла build.

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

в корне вашего проекта 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()
корневой каталог проекта может также содержать где вы определяете свойства, используемые вашими проектами:
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 автоматически рассмотрит все ваши определения, выполненные в различных файлы.

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