Грабли 1 month later
С лёгкой подачи начал рыть в сторону gradle.
По дороге ещё подлили масла в огонь, хотя аргументы мне показались слабыми.
Почему: раньше проект мы собирали антом, и к настоящему моменту мы пришли к тому
что в ant приходится слишком много копипастить. Конкретно в ant мне не хватает вменяемого
способа работы в path и fileset, что бы из одного можно было сделать другое и наоборот,
что бы можно было было просто объединять их. Увы в ant этого сделать нельзя.
Кроме того в ant очень плохо с полиморфизмом/наследованием,
создать скрипт котоый будет собирать единообразно несколько
модулей можно, но очень трудно (см. скрипты сборки NetBeans).
Почему не: maven не подходит потому что под него нужно заранее делать структуру
проекта и сейчас всё переделывать уже поздно. Можно было покопать ant+ivy что
бы разрулить проблемы с зависимостями (которые в общем то занимаю большую часть кода)
но как то не срослось.
Я уж было думал писать скрипт сборки на java использую ant наппрямую, new org.apache.ant.Project(bla bla),
но тут подвернулись gradle.
Впечатление: не могу назвать gradle ни быстрой - больше секунды на то что бы пробурчатся
прежде чем начать что то делать это не круто,
ни красиво реализованной (интеграция с антом переодически выдаёт чудные баги, т.е. не везде можно
вызывать любые ant команды, причины понятны и объяснимы - ант кривой - но не радуют).
Довольно смутно понятно какие объекты где доступны, почему вроде бы глобалные final
значения недоступны в методах но доступны в таргетах (навреное я мало знаю groovy, но в общем то
знаний хватило).
А вот порадовало то что врождённые проблемы ant-а пропали сами собой.
Нет проблем со сборкой многих похожих модулей, я сделал пару базовый классов ModuleJar,
ModuleWar extends ModuleJar и от них унаследовал столько конкретных модулей сколько
мне нужно. Т.е. javac мне не пришлось копипастить 10 раз.
Тут ещё момогла возможность динамического создания таргетов.
Разрулились проблемы с classpath - все зависимоти я распихал по спискам и тосую их как хочу,
а потом уже переделываю их в ant структуры - такие - какие мне нужны.
Нужны jar-ы для компиляции - генерим path, нужны для сборки war - генерим fileset.
Мораль: в общем то, как и говорит автор проекта, gradle хорош если нужно писать
действительно сложные скрипты сборки. Когда нужно скрипт подогнать под окружение а не наоборот.
С gradle не чувствуешь себя с завязанными руками как в ant или с руками застёгнутыми наручниками между ног как в maven.
По дороге ещё подлили масла в огонь, хотя аргументы мне показались слабыми.
Почему: раньше проект мы собирали антом, и к настоящему моменту мы пришли к тому
что в ant приходится слишком много копипастить. Конкретно в ant мне не хватает вменяемого
способа работы в path и fileset, что бы из одного можно было сделать другое и наоборот,
что бы можно было было просто объединять их. Увы в ant этого сделать нельзя.
Кроме того в ant очень плохо с полиморфизмом/наследованием,
создать скрипт котоый будет собирать единообразно несколько
модулей можно, но очень трудно (см. скрипты сборки NetBeans).
Почему не: maven не подходит потому что под него нужно заранее делать структуру
проекта и сейчас всё переделывать уже поздно. Можно было покопать ant+ivy что
бы разрулить проблемы с зависимостями (которые в общем то занимаю большую часть кода)
но как то не срослось.
Я уж было думал писать скрипт сборки на java использую ant наппрямую, new org.apache.ant.Project(bla bla),
но тут подвернулись gradle.
Впечатление: не могу назвать gradle ни быстрой - больше секунды на то что бы пробурчатся
прежде чем начать что то делать это не круто,
ни красиво реализованной (интеграция с антом переодически выдаёт чудные баги, т.е. не везде можно
вызывать любые ant команды, причины понятны и объяснимы - ант кривой - но не радуют).
Довольно смутно понятно какие объекты где доступны, почему вроде бы глобалные final
значения недоступны в методах но доступны в таргетах (навреное я мало знаю groovy, но в общем то
знаний хватило).
А вот порадовало то что врождённые проблемы ant-а пропали сами собой.
Нет проблем со сборкой многих похожих модулей, я сделал пару базовый классов ModuleJar,
ModuleWar extends ModuleJar и от них унаследовал столько конкретных модулей сколько
мне нужно. Т.е. javac мне не пришлось копипастить 10 раз.
Тут ещё момогла возможность динамического создания таргетов.
Разрулились проблемы с classpath - все зависимоти я распихал по спискам и тосую их как хочу,
а потом уже переделываю их в ant структуры - такие - какие мне нужны.
Нужны jar-ы для компиляции - генерим path, нужны для сборки war - генерим fileset.
Мораль: в общем то, как и говорит автор проекта, gradle хорош если нужно писать
действительно сложные скрипты сборки. Когда нужно скрипт подогнать под окружение а не наоборот.
С gradle не чувствуешь себя с завязанными руками как в ant или с руками застёгнутыми наручниками между ног как в maven.