Если меня сейчас спросят:"Какую систему сборки ты бы выбрал для своего Java-приложения?" - я бы ответил:"Мавен", но не потому что он лучший а просто потому что я его тупо знаю. На самом деле если вы никогда не пользовались мавеном, то лучше с ним не связывайтесь, а переходите сразу к Gradle.
Дело в том что XML конечно штука строгая и точная, но логика у мавена очень запутанная, возникает много вопросов, например: в каком порядке будут выполняться плагины в одной фазе? Хорошо, неважно, но тогда будет ли <pluginManagement> переопределять некоторые настройки плагина в дочернем модуле, которые там не заданы? Даже если у плагина другой ID?
Одна из самых неприятных проблем - проперти наследуются только с помощью parent и нет рабочего плагина в репозитории чтобы зачитать проперти скажем из .properties файла на этапе инициализации, т.е. еще до начала построения дерева зависимостей. А это было бы очень неплохо чтобы использовать одни и те же проперти в разных модулях и при этом не связывать их деревом наследования. Думаете проперти подтянуться если прописать модуль с нужными пропертями как зависимость? Нет - не подтянуться. Можно ли переписать проперти профилем? Да - можно. А если профиль задан в другом помнике, скажем - в родительском? Тогда нет - не получиться. Получается профиль и проперти лежат в одном месте. Может вообще тогда все в одно место засунуть? Угадайте какое.
Как насчет модулей? Что разработчики вкладывали в понятие модуль? Для меня модуль это некий плагин который может попасть в общую сборку или не попасть в нее. В мавене модуль это крючок на который можно повесить помник, чтобы он тоже собирался. Является ли модуль плагином? Нет, его нельзя взять и отключить (если только не профилем). Модуль обязательно должен иметь кого-то в качестве parent, иначе он не получит его настроек. Для меня было бы очевидно что если ты прописываешь
<modules>
<module>module1</module>
<module>modul2</module>
<module>module33</module>
<module>moduleE</module>
</module>
то все эти модули обязательно получат настройки текущего. Текущий как-бы является их родителем ведь он их определяет, так? В мавене не так, родитель он только если ты пропишешь <parent>, а <modules></modules> - это крючки и непонятно будет ли работа этих модулей видна в помнике который их определяет. Например есть такая штука как <scope>import</scope>, используется она только для импорта информации <dependencyManagement> в любой помник. Так вот если у вас есть помник с такой информацией, в котором определены модули с такой информацией, то при импорте инфа из модулей не подхватиться! Это был шок, я хотел сделать иерархию пакетов зависимостей и подключать их одной строчкой, но мавен считает иначе.
Код мавена сложно рефакторить, отсутствие констант и переписывание чего-угодно профилями и дочерними модулями делает отлов ошибки трудным и напоминает скриптинг, где важно знать весь процесс и всю задумку. Хотя задумка самого мавена отнюдь не процедурная, там есть и фазы и параллельное выполнение. Вот получаешь ты ошибку сборки, что первым делом делаешь? Идешь в модуль который не собрался и пытаешься найти какое-нибудь проперти или профиль который переписал значение, или не отработал. Но он может быть и не в этом помнике, может - в родительском? Проперти наследуются, а профили нет.. воу воу, мозг полегче!
В итоге часто имеем противоречие с главным слоганом мавена - "Все уже работает, просто настрой" - приходится самому выдумывать хитрые архитектурные ходы и обманы чтобы заставить этот сборщик работать.
Может дело не в задумке а в языке XML, ведь его так много, глаза болят.
Дело в том что XML конечно штука строгая и точная, но логика у мавена очень запутанная, возникает много вопросов, например: в каком порядке будут выполняться плагины в одной фазе? Хорошо, неважно, но тогда будет ли <pluginManagement> переопределять некоторые настройки плагина в дочернем модуле, которые там не заданы? Даже если у плагина другой ID?
Одна из самых неприятных проблем - проперти наследуются только с помощью parent и нет рабочего плагина в репозитории чтобы зачитать проперти скажем из .properties файла на этапе инициализации, т.е. еще до начала построения дерева зависимостей. А это было бы очень неплохо чтобы использовать одни и те же проперти в разных модулях и при этом не связывать их деревом наследования. Думаете проперти подтянуться если прописать модуль с нужными пропертями как зависимость? Нет - не подтянуться. Можно ли переписать проперти профилем? Да - можно. А если профиль задан в другом помнике, скажем - в родительском? Тогда нет - не получиться. Получается профиль и проперти лежат в одном месте. Может вообще тогда все в одно место засунуть? Угадайте какое.
Как насчет модулей? Что разработчики вкладывали в понятие модуль? Для меня модуль это некий плагин который может попасть в общую сборку или не попасть в нее. В мавене модуль это крючок на который можно повесить помник, чтобы он тоже собирался. Является ли модуль плагином? Нет, его нельзя взять и отключить (если только не профилем). Модуль обязательно должен иметь кого-то в качестве parent, иначе он не получит его настроек. Для меня было бы очевидно что если ты прописываешь
<modules>
<module>module1</module>
<module>modul2</module>
<module>module33</module>
<module>moduleE</module>
</module>
то все эти модули обязательно получат настройки текущего. Текущий как-бы является их родителем ведь он их определяет, так? В мавене не так, родитель он только если ты пропишешь <parent>, а <modules></modules> - это крючки и непонятно будет ли работа этих модулей видна в помнике который их определяет. Например есть такая штука как <scope>import</scope>, используется она только для импорта информации <dependencyManagement> в любой помник. Так вот если у вас есть помник с такой информацией, в котором определены модули с такой информацией, то при импорте инфа из модулей не подхватиться! Это был шок, я хотел сделать иерархию пакетов зависимостей и подключать их одной строчкой, но мавен считает иначе.
 |
| Maven repo dependencies |
Код мавена сложно рефакторить, отсутствие констант и переписывание чего-угодно профилями и дочерними модулями делает отлов ошибки трудным и напоминает скриптинг, где важно знать весь процесс и всю задумку. Хотя задумка самого мавена отнюдь не процедурная, там есть и фазы и параллельное выполнение. Вот получаешь ты ошибку сборки, что первым делом делаешь? Идешь в модуль который не собрался и пытаешься найти какое-нибудь проперти или профиль который переписал значение, или не отработал. Но он может быть и не в этом помнике, может - в родительском? Проперти наследуются, а профили нет.. воу воу, мозг полегче!
В итоге часто имеем противоречие с главным слоганом мавена - "Все уже работает, просто настрой" - приходится самому выдумывать хитрые архитектурные ходы и обманы чтобы заставить этот сборщик работать.
Может дело не в задумке а в языке XML, ведь его так много, глаза болят.
Комментариев нет:
Отправить комментарий