Gradle — одиночный build.gradle с динамическими зависимостями

Итак, у нас есть огромная многопроектная кодовая база со структурой, как показано ниже:

C:\Eclipse\Workspace->
                    AR
                    DC
                    CI
                    ..
                    ..

В каждом проекте есть файл build.gradle, в котором 80% кода одинаково, а для всех проектов меняется только раздел зависимостей.

Чего я хочу достичь:

Я хочу создать родительский проект с именем "BuildAllProjects", который будет ЕДИНСТВЕННЫМ проектом, имеющим build.gradle, settings.gradle и gradle.properties, и предлагаю иметь файл свойств для упоминания зависимостей каждого проекта. , что-то типа:

AR=j2ee,commons-lang,FW,DA,Common
DC=commons-codec,FW,DA,Common,spring-core

а затем используйте свойства gradle expand[] для динамического заполнения зависимостей для проекта, который я создаю, поэтому, например, если я создаю AR, я могу запустить:

gradle -PAR build

который будет читать зависимости для «AR» из свойств и раскрывать в форме:

dependencies {
   compile name 'j2ee'
   compile name 'commons-lang'
}

Как вы думаете, ребята, это возможно или это САМЫЙ ХУДШИЙ способ добиться этого? Я новичок в GRADLE в целом, и информация, представленная выше, основана на знаниях, которые я приобрел за несколько недель. Пожалуйста, предоставьте свои предложения по реализации этого в ЛУЧШЕМ из градации.

Спасибо, Йогендра.


gradle build.gradle
person Yogendra    schedule 25.05.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Наложение языка сборки на основе файла свойств поверх языка сборки Gradle не кажется мне желательным. Вместо этого я рекомендую сосредоточиться на написании чистых и СУХИХ сценариев сборки Gradle. Вы можете узнать больше о мощных возможностях абстракции Gradle (внедрение конфигурации, плагины сценариев, buildSrc, пользовательские плагины и расширения и т. д.) в Руководство пользователя Gradle.

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

person Peter Niederwieser    schedule 25.05.2014
comment
так что вы имеете в виду, что каждый подпроект по-прежнему будет иметь build.gradle, но будет иметь только зависимости, в то время как остальная часть 80% кода будет находиться в корневом build.gradle? Я до сих пор не могу понять, как два файла сборки Gradle используют друг друга? - person Yogendra; 25.05.2014
comment
Все это объясняется в Руководстве пользователя Gradle. - person Peter Niederwieser; 25.05.2014