Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Очень рекомендую сразу почитать о более гибких системах сборки. Начиная от ant и заканчивая buildr, gradle и прочими.
Мавен — оказывается крайне неудобен как только требуется сделать шаг в сторону от стандартного процесса =(
Мавен — оказывается крайне неудобен как только требуется сделать шаг в сторону от стандартного процесса =(
где-то я уже читал такой коммент, тоже в топике по мавену. Поищу, бы какой-то контрответ на это.
Кстати, а не сами ли человеки из Apache рекомендуют переходить от Ant к Maven? Одного же стойла кобылы, конюхи не должны обманывать
Кстати, а не сами ли человеки из Apache рекомендуют переходить от Ant к Maven? Одного же стойла кобылы, конюхи не должны обманывать
Смысл переходить от ант к мавен есть, безусловно. Но уже довольно давно у анта есть ivy так сто преимущества мавена уже не так очевидны.
А по поводу продвинутых билд систем, есть интересная статья Фаулера про rake martinfowler.com/articles/rake.html — именно эту тулзу и пытаются повторить buildr/gradle и тп
А по поводу продвинутых билд систем, есть интересная статья Фаулера про rake martinfowler.com/articles/rake.html — именно эту тулзу и пытаются повторить buildr/gradle и тп
довелось поведать проект, который собирался с помощью Rake. Тот ад, что творился в его коде, я боюсь даже вспоминать. Мало того, что оно перед билдом требовало установки кучу гемов (а собирали флеш клиент + руби сервер), так ещё и после руби-синтаксиса (а его там было over1k строк) ковыряться в этом было ну просто невозможно.
Люблю ant за его простой и очень структуированный синтаксис. Минимум лишнего, имхо. Любой другой программист, взглянув на build-файл, может легко его понять, а в случае с Rake получаем очень высокий порог входа для человека, не знающего Ruby.
Люблю ant за его простой и очень структуированный синтаксис. Минимум лишнего, имхо. Любой другой программист, взглянув на build-файл, может легко его понять, а в случае с Rake получаем очень высокий порог входа для человека, не знающего Ruby.
и, да, Maven хорош для Java проектов, но вот собирать что-то другое (к примеру, Flex проекты) — это ад (на момент, когда я последний раз изучал этот вопрос)
На текущий момент отлично собирается.
я использую собственную модификацию mxmlc, позволяет ли оно указывать кастомную Flex SDK?
Таки ой. С этим сложнее. Зависимость на кастомный sdk дать можно, правда тут его руками в репозиторий поставить придется. Но вот не уверен что компилятор возьмется из sdk а не из плагина flexmojos
значит ничего не изменилось =)
Maven хорош, когда не отходишь от стандартного пути. Для всего остального естьmastercard ant! (для меня, по крайней мере)
Maven хорош, когда не отходишь от стандартного пути. Для всего остального есть
Ант не хорош, когда отходишь от стандартного пути чуть дальше, чем предусмотрели его создатели :) Тогда остается использовать скрипты на руби/питоне, и вызывать их из основной антовской инфраструктуры билда.
*повидать, конечно же
если это был джава проект, то пожалуй да, голый рейк не очень подходит
а вот билд файл на buildr/gradle не так уж страшен
в конце концов порог вхождения в мавен при котором можно сделать билд, соответствующий тому, что Вы видели на rake я думаю будет не сильно ниже ;)
а вот билд файл на buildr/gradle не так уж страшен
в конце концов порог вхождения в мавен при котором можно сделать билд, соответствующий тому, что Вы видели на rake я думаю будет не сильно ниже ;)
Проблема в том, что Ant — это декларативный язык, поддерживающий по большому счету стандартизированные операции. Еслм не надо например, реализовать свою систему управлениями зависимостей модулей, скрипты, которые загружают все модули, компилируют их, и автоматически создают работающий и готовый к использованию воркспейс, — да хотя бы использовать банальную логику if/else/, циклы и прочее — в анте это сделать можно, но достаточно геморройно. Сравните как вы пишете например, цикл в анте, и как в руби. Есть разница?
Мы используем активно Ant / Ivy, во многих сложных местах у нас в ант встроены скрипты, написанные на Jython.
Мы используем активно Ant / Ivy, во многих сложных местах у нас в ант встроены скрипты, написанные на Jython.
Одно из преимуществ — это то, что POM — это структурное описание проекта, тогда как build.xml — просто инструкция по сборке. Это позволяет Maven'у, например, автоматически генерить проект для IDE.
Но у меня от Maven'а остались в основном негативные впечатления. Таки да, шаг влево/шаг вправо — и начинаются дикие трудности. Кроме того, если возникают проблемы, то их очень трудно диагностировать. У меня, например, был случай, когда Maven на нашем билд-сервере незаметно апгрейднулся, и в результате начал использовать библиотеки в немножечко другом порядке. Я убил два с половиной дня, пытаясь понять, почему сборка на моём компьютере и на сервере даёт разные результаты.
Но у меня от Maven'а остались в основном негативные впечатления. Таки да, шаг влево/шаг вправо — и начинаются дикие трудности. Кроме того, если возникают проблемы, то их очень трудно диагностировать. У меня, например, был случай, когда Maven на нашем билд-сервере незаметно апгрейднулся, и в результате начал использовать библиотеки в немножечко другом порядке. Я убил два с половиной дня, пытаясь понять, почему сборка на моём компьютере и на сервере даёт разные результаты.
Сам пользуюсь антом и иногда батниками. Всё время видел утверждения что надо уходить от анта к Maven, но внятных аргументов не видел. Вот, почитываю про maven иногда, но сам ещё не определился окончательно. Может надо попробовать оба в крупных проектах, и потом сделать вывод? Ант меня местами не устраивает.
мавен принципиально декларативен — по своей натуре, это накладывает очень серьезные ограничения на то, что можно сделать с билдом =(
при переходе с анта вещи типа «а еще я хочу чтобы вот этот файлик при билде копировался отсюда туда — как это сделать? НИКАК!» вызывают нехилый диссонанс
при переходе с анта вещи типа «а еще я хочу чтобы вот этот файлик при билде копировался отсюда туда — как это сделать? НИКАК!» вызывают нехилый диссонанс
Спасибо. Больше тогда maven не рассматриваю. У меня деплой на тест сервер идёт автоматом при каждом билде, причём у каждого разработчика в свою папку.
Развёртывание системы и её сборка — ортогональные проблемы. Поручите их разным тулам и ваша жизнь станет проще.
Может я чего не понимаю, но использую ант в чисто императивном стиле. Запустить это с такими параметрами, переместить сюда, переименовать в это, потом с этим ещё собрать что-то, потом результат переместить на сервак. Я как раз не вижу разницы между деплоем и сборкой. Можете подсказать статейки которые бы изменили мой взгляд?
Learn You a Haskell for Great Good
Шутка. Пролог лучше изгоняет императивность из сознания =)
То, что Вы предлагает — это конвеер по сборке машин доставлющий их прямо к гаражу. Реализуемо, вроде удобно, но количество получаемых проблем не имеющих отношения к процессу будет доминировать над основной задачей — сборкой машины. Посмотрите как например Continuum берёт на себя вопросы деплоя и тэгирования в scm избавляя сборку от заботы об этих вопросах.
Шутка. Пролог лучше изгоняет императивность из сознания =)
То, что Вы предлагает — это конвеер по сборке машин доставлющий их прямо к гаражу. Реализуемо, вроде удобно, но количество получаемых проблем не имеющих отношения к процессу будет доминировать над основной задачей — сборкой машины. Посмотрите как например Continuum берёт на себя вопросы деплоя и тэгирования в scm избавляя сборку от заботы об этих вопросах.
Имхо это вопрос религиозный. Мне вот гораздо проще когда одна команда (код для который лежит в scm) делает мне хорошо — билд, тест, деплой (если тест прошел) ну и т.п.
Я тоже исповедовал такой подход. Потом появился проект с двумя десятками модулей в разработке половины из которых я не принимал участие.
Попытка посторить систему сборки на ant+ivy привела к xml на 2000 строк + 300-500 строк на каждый модуль + по 20 строк .properties + 100 строк .sh для деплоя и меток в CVS + необходимость доносить до людей нетривиальные соглашения по конфигурации проектов чтобы это работало + hand made репозитарий артефактов. Почти 2 месяцаполучал фан потерял. Слава богу административные задержки не позволили распространить эту конструкцию и дали время переехать на maven.
Альтернативой стал стэк maven + continuum + archiva. 150 строк общего pom + по 50-100 на модуль, .properties по 10 строк. Всё тэгирование и деплой на совести continnum. Структурированное хранилище с индексацией по именам артефактов и их содержимомму а также несколькими репозитариями для разных команд archiva. Всего около 3 недель.
И да, большинство модулей паковалось как RCP-плагины, часть зависело от импорта WSDL через утилиты JAX-WS. Это на тему невозможности решения нестандартных проблем.
Попытка посторить систему сборки на ant+ivy привела к xml на 2000 строк + 300-500 строк на каждый модуль + по 20 строк .properties + 100 строк .sh для деплоя и меток в CVS + необходимость доносить до людей нетривиальные соглашения по конфигурации проектов чтобы это работало + hand made репозитарий артефактов. Почти 2 месяца
Альтернативой стал стэк maven + continuum + archiva. 150 строк общего pom + по 50-100 на модуль, .properties по 10 строк. Всё тэгирование и деплой на совести continnum. Структурированное хранилище с индексацией по именам артефактов и их содержимомму а также несколькими репозитариями для разных команд archiva. Всего около 3 недель.
И да, большинство модулей паковалось как RCP-плагины, часть зависело от импорта WSDL через утилиты JAX-WS. Это на тему невозможности решения нестандартных проблем.
Можно же такие вещи описывать с помощью maven-ant-plugin, который на нужной фазе сборки выполнит ваш скрипт, и файлик окажется в правильном месте.
И зачем мне тогда такой тандем? Если почти все задачи выполняет ант.
Эта самая декларативность позволяет описать структуру проекта (где каталоги с ресурсами, где с исходниками, где тесты и т.д.), а не порядок шагов его сборки. Поэтому проект может быть легко импортирован в IDE.
вот вопрос про копирование файлика лично у меня не стоял вообще. Смотрите в статье, там этап упаковки проекта, откуда и куда описано в файле assembly.xml
часто бывают существенно более сложные вариации — см например выше про деплой на тест сервер. В мавене это будет решаться отдельным деплой плагином. Что тоже работает до некоторой степени.
Я не могу сказать что с мавено жить совсем невозможно, но есть вероятность, что придется изменять свои процессы, чтобы уложиться в то, что предлагает мавен. Ну или костыли — ant-mave, sh-maven, custom plugin на каждый чих и т.п.
Я не могу сказать что с мавено жить совсем невозможно, но есть вероятность, что придется изменять свои процессы, чтобы уложиться в то, что предлагает мавен. Ну или костыли — ant-mave, sh-maven, custom plugin на каждый чих и т.п.
>> но есть вероятность, что придется изменять свои процессы, чтобы уложиться в то, что предлагает мавен.
В этом суть и сила maven-a. Convention over configuration — все проекты имеют одинаковую структуру, вследствие чего новым разработчикам (которые знают maven) очень легко подхватить любой проект.
В этом суть и сила maven-a. Convention over configuration — все проекты имеют одинаковую структуру, вследствие чего новым разработчикам (которые знают maven) очень легко подхватить любой проект.
все очень просто решается с помощью maven-antrun-plugin.
maven приучает к порядку при сборке. танцы с бубном зависят от требований по сборке.
maven приучает к порядку при сборке. танцы с бубном зависят от требований по сборке.
assembly plugin, не?
копирование решается использованием maven-ant-plugin (если не хватает более подходящих вещей, заточенные на конкретные типы сборки, вроде maven-assembly-plugin)
вы просто не умеете его готовить.
если вам надо скопировать файлы ресурсов, то есть теги resources и testResources. Если надо скопировать после сборки, то используйте уже явно плагин maven-copy-plugin с Goal «copy-resources» и тогда не будет никаких диссонансов.
UPD: Если под копированием файлов имеется в виду копирование зависимостей, то используйте maven-dependency-plugin + wagon-maven-plugin
если вам надо скопировать файлы ресурсов, то есть теги resources и testResources. Если надо скопировать после сборки, то используйте уже явно плагин maven-copy-plugin с Goal «copy-resources» и тогда не будет никаких диссонансов.
UPD: Если под копированием файлов имеется в виду копирование зависимостей, то используйте maven-dependency-plugin + wagon-maven-plugin
Я тут как-то написал псто на эту тему. Был молод и неумён, но предпоследний раздел вроде отвечает на ваш вопрос.
Сам работал когда-то с Антом. Как только начнутся многомодульные проекты + сложные библиотечные зависимости — Ант можно выбрасывать и брать Maven.
Управление зависимостями — это основное преимущество мавена. Мавен устроен по принципу convention over configuration — многие люди путают это с негибкостью :)
Еще было бы интересно, если бы вы описали чем вас не устраивает ант, я бы попробовал прикинуть эти проблемы к мавену.
П.С. номер ревизии для меркуриал делали так:
Еще было бы интересно, если бы вы описали чем вас не устраивает ант, я бы попробовал прикинуть эти проблемы к мавену.
П.С. номер ревизии для меркуриал делали так:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<id>mercurial-revision</id>
<phase>validate</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>hg</executable>
<arguments>
<argument>id</argument>
</arguments>
<outputFile>${basedir}/src/main/webapp/static/revision.txt</outputFile>
</configuration>
</plugin>
А Вы пробовали сделать шаг в сторону в Gradle?
В maven это выливается в 10 минут на сочинение правильного запроса к гуглу. Найденное решение не всегда блещет элегантностью, но оно есть.
В Gradle это выливается в 4-6 часов чтения его исходников и реверсинжиниринга DSL. Причина: документация далека от исчерпывающей, DSL не консистентен, а тул не настолько популярен, чтобы находились готовые рецепты. Рассылка завалена вопросами вроде «как сделать то?» и «я тут попробовал ваш рецепт и призвал сатану».
В maven это выливается в 10 минут на сочинение правильного запроса к гуглу. Найденное решение не всегда блещет элегантностью, но оно есть.
В Gradle это выливается в 4-6 часов чтения его исходников и реверсинжиниринга DSL. Причина: документация далека от исчерпывающей, DSL не консистентен, а тул не настолько популярен, чтобы находились готовые рецепты. Рассылка завалена вопросами вроде «как сделать то?» и «я тут попробовал ваш рецепт и призвал сатану».
Я пробовал.
Да, тул не настолько популярен, чтобы были готовые рецепты на все случаи жизни. Да, по-моему, где-то в самом начале пришлось таки залезть разок в его исходники :). Да, документация оставляет желать…
Но сама возможность писать на человеческом языке вместо хардкорных иксэмэльных портянок лично для меня перевешивает :)
Да, тул не настолько популярен, чтобы были готовые рецепты на все случаи жизни. Да, по-моему, где-то в самом начале пришлось таки залезть разок в его исходники :). Да, документация оставляет желать…
Но сама возможность писать на человеческом языке вместо хардкорных иксэмэльных портянок лично для меня перевешивает :)
А Polyglot вы не пробовали? Вполне человечно получается, судя по описанию.
НеБ я не пробовал. А это что-то бОльшее, чем билдер мавеновских конфигураций? Я из поверхностного лазанья по сайту не смог это сходу понять…
По замыслу это заменяет «хардкорные иксэмэльные портянки» на удобочитаемую конфигурацию в виде Groovy кода
Понятно, значит я правильно понял. В этом есть свои преимущества, но есть и недостатки. Как, впрочем, и везде :). Останусь на gradle, проекты у меня небольшие и проблема со вхождением новых участников, привыкших к мавену и не могущих переучиться, в проект не стоит остро. Ну, и «плюс пара проектов» на gradle в мире послужит его популяризации :)
Вопрос не в тему: а вы с Firebird в Java через ORM работаете?
Спасибо за то, что рассказали про buildnumber-maven-plugin. Как-то он раньше проскользнул мимо меня, но как раз есть где его применить.
Мы сделали вот так сборку 100+ разных проектов (Java библиотек, Web приложений)
— Все проекты имеют .project, .classpath от Eclipse IDE
— Все в Subversion
— Все проекты занесены в Hudson/Jenkins для автоматического билда и развертывания.
Написали два стандартных билд скрипта на ant, которые, используя ant4eclipse, скачивают из Subversion и компилируют проект с соответствии с зависимостями, объявленными в .classpath.
Для Java библиотек для сборки jar файла используется парсер jar.jardesc файла который был создан в Eclipse.
Для Web приложений собирается в соответствии с местным .build.properties.
— Все проекты имеют .project, .classpath от Eclipse IDE
— Все в Subversion
— Все проекты занесены в Hudson/Jenkins для автоматического билда и развертывания.
Написали два стандартных билд скрипта на ant, которые, используя ant4eclipse, скачивают из Subversion и компилируют проект с соответствии с зависимостями, объявленными в .classpath.
Для Java библиотек для сборки jar файла используется парсер jar.jardesc файла который был создан в Eclipse.
Для Web приложений собирается в соответствии с местным .build.properties.
вся портянка про «Далее требовалось перед сборкой в jar-архив скидать все ресурсы (картинки и .properties-файлы) в директорию со скомпилированными .class-файлами.» не нужна, если ресурсы положить в scr/main/resources вместо src/main/java — Maven тогда сам сделает именно то, что вы «навелосипедили» (он даже сам догадается не фильтровать картинки)
Люди, милые мои, ну как, как при живом gradle вас заносит начинать новые проекты на maven? что-ж это за мазохизм-то такой?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От велосипеда к Maven