Comments 5
Используйте application плагин, он куда удобнее, не нужно добавлять зависимость на еще один плагин и он не является хаком как вся концепция shadow jar
А еще можно сделать руками кеширование базового слоя со всеми зависимостями используя только application plugin
TestNG при Junit 5 тоже выглядит странным, я бы не рекомендовал его сегодня как решение "по умолчанию"
Ну и нативный mockk куда лучше mockito-kotlin, конечно только если у вас уже не готовое приложение и вы мигрируете на Kotlin новые/старые тесты
Например, несколько библиотек в приложении используют HOCON для конфигурации и предоставляют reference.conf с настройками по умолчанию в classpath. Такая конфигурация будет работать как есть в application плагине, а вот с shadowJar придется поплясать.
Не зря в shadow плагине есть куча мерджеров которые умеют склеивать (это к примеру) сервисы поставляемые через Service Loader API, да и вообще куча конфигурации которая нужна просто потому что shadow jar это хак. Хуже всего если у вас бинарные данные (набор картинок по одному урлу или конфигурация в протобаф, тут придется писать свой кастомный мерджер)
Можно зайти в issues и увидеть кучу проблем связанных с этим https://github.com/johnrengelman/shadow/issues/640
Второй момент — с shadow jar сложнее делать кеширующий слой в докере, для application я написал таску в пять строк которая делает две папки с базовыми либами и приложением, с shadow jar не знаю как это будет решаться.
Ну и в целом: два плагина + потенциальные проблемы с конфигурацией, вместо того что и так работает с дефолтным плагином? Тем более, чтобы запускать в докере? Нет, KISS
Таска просто генерит папочки, остальная логика в Jenkins:
Смысл в таске такой (реализация подсмотрена в application/distibution плагине):
with(project.copySpec().apply {
into("app")
from(project(":$prj").tasks.jar)
})
with(project.copySpec().apply {
into("app")
from(project(":$prj").configurations.runtimeClasspath)
})
Шаблон Kotlin микросервисов