Копирование файлов на основе шаблона, определенного после завершения фазы конфигурации

Question

В настоящее время я оцениваю gradle как альтернативу Maven для сборки муравейника + плюща, созданного на собственной конвенции. Сборка ant + ivy разработана для обеспечения стандартной среды для широкого спектра приложений j2se и поддерживает следующую стандартную компоновку для конфигурации приложения

conf/
    fooPROD.properties
    fooUAT.properties
    bar.properties
    UK/
        bazPROD.properties
        bazUAT.properties

Если я выберу сборку для UAT, я получу

conf/
    foo.properties
    bar.properties
    UK/
        baz.properties

т.е. он копирует файлы с суффиксом целевой среды (в данном случае UAT), а также все, что не имеет такого шаблона. Наряду с этим происходит множество других вещей, которые усложняют ситуацию, но это является ядром моей нынешней проблемы.

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

tasks.addRule("Pattern: make<ID>") { String taskName ->
    task(taskName).dependsOn tasks['make']
}

Задача make имеет дело с различным копированием / фильтрацией / преобразованием файлов conf из src в область сборки. Для этого нужно выяснить, что представляет собой targettenv, которым я сейчас занимаюсь после создания DAG

gradle.taskGraph.whenReady {taskGraph ->
    def makeTasks = taskGraph.getAllTasks().findAll{ 
        it.name.startsWith('make') && it.name != 'make' 
    }
    if (makeTasks.size() == 1) {
        project.targetEnv = makeTasks[0].name - 'make'
    } else {
        // TODO work out how to support building n configs at once
    }
}

(такое чувство, что должен быть более быстрый / более идиоматический способ сделать это, но я отвлекся)

Затем я могу запустить его как gradle makeUAT

Моя проблема в том, что установка targetEnv таким образом означает, что targetEnv не установлен во время конфигурации. Поэтому, если у меня есть задача копирования, как

task prepareEnvSpecificDist(type: Copy) {
    from 'src/main/conf'
    into "$buildDir/conf"
    include "**/*$project.targetEnv.*"
    rename "(.*)$project.targetEnv.(.*)", '$1.$2'
}

он не делает то, что я хочу, потому что $project.targetEnv еще не установлен. Наивно я изменил это на

task prepareEnvSpecificDist(type: Copy) << {
    from 'src/main/conf'
    into "$buildDir/conf"
    include "**/*$project.targetEnv.*"
    rename "(.*)$project.targetEnv.(.*)", '$1.$2'
}

однажды я понял, что происходит. Это тогда терпит неудачу как

Skipping task ':prepareEnvSpecificDist' as it has no source files.

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

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

NB: Я понимаю, что могу передать системное свойство и сделать что-то вроде gradle -Dtarget.env=UAT make, но это довольно многословно, и я все равно хочу разобраться, что происходит.

Приветствия

Мэтт

Answer 1

Построение для конкретной целевой среды является сквозной задачей и не совсем соответствует характеру задачи. Использование системного свойства (-D) или свойства проекта (-P) является естественным способом решения этой проблемы.

Если вы абсолютно хотите сохранить несколько символов, вы можете запросить и манипулировать gradle.startParameter.taskNames, чтобы реализовать переключатель среды, который выглядит как имя задачи. Однако это нестандартное решение.

Как можно решить проблему настройки задачи на основе свойств, которые становятся конкретными после ее завершения?

Это частный случай более общей проблемы, когда значение конфигурации записывается после того, как оно было прочитано. Типичные решения:

1. Избегайте, если можете.
2. Некоторые свойства задачи / модели допускают закрытие, которое затем будет обрабатываться лениво Это необходимо найти в соответствующей документации по заданию / плагину.
3. Выполните конфигурацию в глобальном хуке, например gradle.projectsEvaluated или gradle.taskGraph.whenReady (в зависимости от конкретных потребностей).
4. Выполнить настройку в действии задачи (во время выполнения). Как вы уже поняли, это работает не во всех случаях и обычно не рекомендуется (но иногда терпимо).
5. Плагины используют условное отображение для ленивой привязки значений модели к свойствам задачи. Это продвинутый метод, который не следует использовать в сценариях сборки, но он необходим для написания плагинов, расширяющих язык сборки.

В качестве примечания, помните, что Gradle позволяет вам вводить свои собственные абстракции. Например, вы можете добавить метод, который позволит вам написать:

environment("uat") {
    // special configuration for UAT environment
}