mikkriСейчас используем OpenDeploy, но результаты получаются весьма странные порой. Один из ключевых недостатков OpenDeploy в том, что программа не интегрирована в процесс упаковки приложений, а значит программа может оказаться частично развернутой из-за того, что часть файлов не попала в OpenDeploy или еще что-то не так случилось. Плюс OpenDeploy настроен только на Production и DR, но не на DEV / UAT. Раз собранный RPM можно было б использовать везде, как я понимаю.Можно ссылку на сайт OpenDeploy? гугл слишком много лишнего выдает.

А почему не получается использовать WAR / EAR?

mikkri2) Насколько я понимаю, сборку RPM вполне легко можно автоматизировать.что то мне казалось, что "скрипт" сборки RPM не проще чем ant build.xml

И соответственно ant clean prepare-for-<type of install> install проще чем rpm install <>.rpm
инсталл все равно нужно на сервере запускать или руками или автоматом.

IMHO для java-иста проще ant скрипт писать / править чем RPM.

mikkri3) WAR, EAR - это только для enterprise applications, т.е. не для standalone. Во-вторых, конфигурационные файлы, которые зависят от среды выполнения (какой сервер, продакшен или UAT или DEV, и т.п.) затруднительно паковать внутрь таких архивов. Потом, WAR и EAR тоже ведь не с неба падают, а должны попадать в production каким-то понятным и контролируемым образом.RPM должен сделать конфиг файлы и ant тоже.
RPM должен собрать rpm файлы и ant тоже (WAR/EAR/JAR).
RPM должен подложить файлы в нужные места и ant тоже.

А в чем принципиальная разница RPM и WAR + конфиги? что будет проще настраивать и инсталлить - еще вопрос.


PS как то на ant нужно было сделать подобиет билд-сервера. Сделал build.xml + запускал по cron-у.

mikkriИ еще одна проблема с Ant - он будет работать локально. Когда нужно пакет установить на, скажем, 12 серверов, это работать не будет.в общем да. Тогда нужно узнавать ЧЕМ пользуются админы и делать под них.

Так пусть админы и объясняют вас КАК это добро собрать в пакет (как пользоваться rpm)