Gradle - когда плагин предпочтительнее скрипта?

Question

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

Другими словами, каждый артефакт содержит все, что ему нужно для запуска - за исключением JDK.

Структура проекта выглядит примерно так:

Root project 'proto' - This is the master-build project
+--- Project ':applications' - Default build settings for applications
|    +--- Project ':applications:foo' - Foo API
|    +--- Project ':applications:bar' - Bar API
|    \--- Project ':applications:baz' - Baz API
+--- Project ':common' - Common code shared by multiple projects
|    \--- Project ':common:subcomponents' - Settings shared by subcomponents
|         +--- Project ':common:subcomponents:configuration' - Configuration
|         \--- Project ':common:subcomponents:initializer' - Initializers
+--- Project ':servers' - Default tasks for building server artifacts
|    +--- Project ':servers:foobar' - Assembles and runs the foobar server
|    +--- Project ':servers:foobaz' - Assembles and runs the foobaz server
|    \--- Project ':servers:barbaz' - Assembles and runs the barbaz server
\--- Project ':webapps' - These are the defaults for webapps
     +--- Project ':webapps:foo' - The webapp for foo
     +--- Project ':webapps:bar' - The webapp for bar
     \--- Project ':webapps:baz' - The webapp for baz

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

Мой текущий подход заключается в том, чтобы использовать пустой сервер в папке «Servers» и копировать его содержимое на создаваемый сервер taget, затем копировать на него файлы war и архивировать все… номой root / servers / build.gradle начинает выглядеть беспорядочно.

Итак, вопрос в том, поможет ли написание плагина 'ear' в стиле, упростить сборку моего сервера?

Также следует отметить, что в настоящее время я использую смолу-pro-3.0.25, но планирую в ближайшее время перейти на другой серверный контейнер (в ближайшие пару месяцев), что ставит меня перед касающимся вопросом - другие люди используютПодобные подходы при создании серверных артефактов для tomcat / jetty?

Ваши мысли очень ценятся!

Answer 1

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

Я полагаю, что подпроекты :servers хранят некоторую конфигурацию для внедрения в дистрибутив, поэтому ваша структура имеет смысл для меня. Затем сценарий определит новую задачу, которая будет извлекать все файлы по соглашению (общая структура каталогов для проекта :servers, принимая WAR из подпроекта :webapps с тем же именем, что и тот, над которым мы выполняем ...) .

Что касается вашего последнего вопроса, я думаю, что это зависит от целевой ОС - например, если бы это был Debian, возможно, для меня более естественным было бы создание пакета, который содержит только WAR приложения и конфигурацию и зависит от пакета контейнера (либо из официального репо, либо созданного вами).