Комментарии 56
Очень рекомендую сразу почитать о более гибких системах сборки. Начиная от ant и заканчивая buildr, gradle и прочими.
Мавен — оказывается крайне неудобен как только требуется сделать шаг в сторону от стандартного процесса =(
Мавен — оказывается крайне неудобен как только требуется сделать шаг в сторону от стандартного процесса =(
0
где-то я уже читал такой коммент, тоже в топике по мавену. Поищу, бы какой-то контрответ на это.
Кстати, а не сами ли человеки из Apache рекомендуют переходить от Ant к Maven? Одного же стойла кобылы, конюхи не должны обманывать
Кстати, а не сами ли человеки из Apache рекомендуют переходить от Ant к Maven? Одного же стойла кобылы, конюхи не должны обманывать
+1
Смысл переходить от ант к мавен есть, безусловно. Но уже довольно давно у анта есть ivy так сто преимущества мавена уже не так очевидны.
А по поводу продвинутых билд систем, есть интересная статья Фаулера про rake martinfowler.com/articles/rake.html — именно эту тулзу и пытаются повторить buildr/gradle и тп
А по поводу продвинутых билд систем, есть интересная статья Фаулера про rake martinfowler.com/articles/rake.html — именно эту тулзу и пытаются повторить buildr/gradle и тп
+2
довелось поведать проект, который собирался с помощью Rake. Тот ад, что творился в его коде, я боюсь даже вспоминать. Мало того, что оно перед билдом требовало установки кучу гемов (а собирали флеш клиент + руби сервер), так ещё и после руби-синтаксиса (а его там было over1k строк) ковыряться в этом было ну просто невозможно.
Люблю ant за его простой и очень структуированный синтаксис. Минимум лишнего, имхо. Любой другой программист, взглянув на build-файл, может легко его понять, а в случае с Rake получаем очень высокий порог входа для человека, не знающего Ruby.
Люблю ant за его простой и очень структуированный синтаксис. Минимум лишнего, имхо. Любой другой программист, взглянув на build-файл, может легко его понять, а в случае с Rake получаем очень высокий порог входа для человека, не знающего Ruby.
+3
и, да, Maven хорош для Java проектов, но вот собирать что-то другое (к примеру, Flex проекты) — это ад (на момент, когда я последний раз изучал этот вопрос)
+1
На текущий момент отлично собирается.
0
я использую собственную модификацию mxmlc, позволяет ли оно указывать кастомную Flex SDK?
0
Таки ой. С этим сложнее. Зависимость на кастомный sdk дать можно, правда тут его руками в репозиторий поставить придется. Но вот не уверен что компилятор возьмется из sdk а не из плагина flexmojos
0
значит ничего не изменилось =)
Maven хорош, когда не отходишь от стандартного пути. Для всего остального естьmastercard ant! (для меня, по крайней мере)
Maven хорош, когда не отходишь от стандартного пути. Для всего остального есть
+1
Ант не хорош, когда отходишь от стандартного пути чуть дальше, чем предусмотрели его создатели :) Тогда остается использовать скрипты на руби/питоне, и вызывать их из основной антовской инфраструктуры билда.
0
в таких редких случаях я пишу либу на Java, и ложу рядом с билд-скриптом, в итоге у конечного пользователя сборка пройдёт успешно без выкачивания тон гемов, установки каких-то библиотек и прочего. Всё, что нужно — это java и ant, ничего лишнего.
0
*повидать, конечно же
0
если это был джава проект, то пожалуй да, голый рейк не очень подходит
а вот билд файл на buildr/gradle не так уж страшен
в конце концов порог вхождения в мавен при котором можно сделать билд, соответствующий тому, что Вы видели на rake я думаю будет не сильно ниже ;)
а вот билд файл на buildr/gradle не так уж страшен
в конце концов порог вхождения в мавен при котором можно сделать билд, соответствующий тому, что Вы видели на rake я думаю будет не сильно ниже ;)
0
Проблема в том, что Ant — это декларативный язык, поддерживающий по большому счету стандартизированные операции. Еслм не надо например, реализовать свою систему управлениями зависимостей модулей, скрипты, которые загружают все модули, компилируют их, и автоматически создают работающий и готовый к использованию воркспейс, — да хотя бы использовать банальную логику if/else/, циклы и прочее — в анте это сделать можно, но достаточно геморройно. Сравните как вы пишете например, цикл в анте, и как в руби. Есть разница?
Мы используем активно Ant / Ivy, во многих сложных местах у нас в ант встроены скрипты, написанные на Jython.
Мы используем активно Ant / Ivy, во многих сложных местах у нас в ант встроены скрипты, написанные на Jython.
0
Одно из преимуществ — это то, что POM — это структурное описание проекта, тогда как build.xml — просто инструкция по сборке. Это позволяет Maven'у, например, автоматически генерить проект для IDE.
Но у меня от Maven'а остались в основном негативные впечатления. Таки да, шаг влево/шаг вправо — и начинаются дикие трудности. Кроме того, если возникают проблемы, то их очень трудно диагностировать. У меня, например, был случай, когда Maven на нашем билд-сервере незаметно апгрейднулся, и в результате начал использовать библиотеки в немножечко другом порядке. Я убил два с половиной дня, пытаясь понять, почему сборка на моём компьютере и на сервере даёт разные результаты.
Но у меня от Maven'а остались в основном негативные впечатления. Таки да, шаг влево/шаг вправо — и начинаются дикие трудности. Кроме того, если возникают проблемы, то их очень трудно диагностировать. У меня, например, был случай, когда Maven на нашем билд-сервере незаметно апгрейднулся, и в результате начал использовать библиотеки в немножечко другом порядке. Я убил два с половиной дня, пытаясь понять, почему сборка на моём компьютере и на сервере даёт разные результаты.
+3
Сам пользуюсь антом и иногда батниками. Всё время видел утверждения что надо уходить от анта к Maven, но внятных аргументов не видел. Вот, почитываю про maven иногда, но сам ещё не определился окончательно. Может надо попробовать оба в крупных проектах, и потом сделать вывод? Ант меня местами не устраивает.
0
мавен принципиально декларативен — по своей натуре, это накладывает очень серьезные ограничения на то, что можно сделать с билдом =(
при переходе с анта вещи типа «а еще я хочу чтобы вот этот файлик при билде копировался отсюда туда — как это сделать? НИКАК!» вызывают нехилый диссонанс
при переходе с анта вещи типа «а еще я хочу чтобы вот этот файлик при билде копировался отсюда туда — как это сделать? НИКАК!» вызывают нехилый диссонанс
+1
Спасибо. Больше тогда maven не рассматриваю. У меня деплой на тест сервер идёт автоматом при каждом билде, причём у каждого разработчика в свою папку.
-1
Развёртывание системы и её сборка — ортогональные проблемы. Поручите их разным тулам и ваша жизнь станет проще.
+1
Может я чего не понимаю, но использую ант в чисто императивном стиле. Запустить это с такими параметрами, переместить сюда, переименовать в это, потом с этим ещё собрать что-то, потом результат переместить на сервак. Я как раз не вижу разницы между деплоем и сборкой. Можете подсказать статейки которые бы изменили мой взгляд?
0
Learn You a Haskell for Great Good
Шутка. Пролог лучше изгоняет императивность из сознания =)
То, что Вы предлагает — это конвеер по сборке машин доставлющий их прямо к гаражу. Реализуемо, вроде удобно, но количество получаемых проблем не имеющих отношения к процессу будет доминировать над основной задачей — сборкой машины. Посмотрите как например Continuum берёт на себя вопросы деплоя и тэгирования в scm избавляя сборку от заботы об этих вопросах.
Шутка. Пролог лучше изгоняет императивность из сознания =)
То, что Вы предлагает — это конвеер по сборке машин доставлющий их прямо к гаражу. Реализуемо, вроде удобно, но количество получаемых проблем не имеющих отношения к процессу будет доминировать над основной задачей — сборкой машины. Посмотрите как например Continuum берёт на себя вопросы деплоя и тэгирования в scm избавляя сборку от заботы об этих вопросах.
0
Имхо это вопрос религиозный. Мне вот гораздо проще когда одна команда (код для который лежит в scm) делает мне хорошо — билд, тест, деплой (если тест прошел) ну и т.п.
0
Я тоже исповедовал такой подход. Потом появился проект с двумя десятками модулей в разработке половины из которых я не принимал участие.
Попытка посторить систему сборки на 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. Это на тему невозможности решения нестандартных проблем.
+3
Можно же такие вещи описывать с помощью maven-ant-plugin, который на нужной фазе сборки выполнит ваш скрипт, и файлик окажется в правильном месте.
+4
И зачем мне тогда такой тандем? Если почти все задачи выполняет ант.
+1
Если все задачи выполняет ант, то надо использовать ант. Другое дело, что maven, несмотря на свою декларативность, позволяет кастомизировать процесс сборки, поэтому утверждение выше, о том, что файлик скопировать нельзя, было неверным.
+2
Эта самая декларативность позволяет описать структуру проекта (где каталоги с ресурсами, где с исходниками, где тесты и т.д.), а не порядок шагов его сборки. Поэтому проект может быть легко импортирован в IDE.
0
вот вопрос про копирование файлика лично у меня не стоял вообще. Смотрите в статье, там этап упаковки проекта, откуда и куда описано в файле assembly.xml
+1
часто бывают существенно более сложные вариации — см например выше про деплой на тест сервер. В мавене это будет решаться отдельным деплой плагином. Что тоже работает до некоторой степени.
Я не могу сказать что с мавено жить совсем невозможно, но есть вероятность, что придется изменять свои процессы, чтобы уложиться в то, что предлагает мавен. Ну или костыли — ant-mave, sh-maven, custom plugin на каждый чих и т.п.
Я не могу сказать что с мавено жить совсем невозможно, но есть вероятность, что придется изменять свои процессы, чтобы уложиться в то, что предлагает мавен. Ну или костыли — ant-mave, sh-maven, custom plugin на каждый чих и т.п.
0
>> но есть вероятность, что придется изменять свои процессы, чтобы уложиться в то, что предлагает мавен.
В этом суть и сила maven-a. Convention over configuration — все проекты имеют одинаковую структуру, вследствие чего новым разработчикам (которые знают maven) очень легко подхватить любой проект.
В этом суть и сила maven-a. Convention over configuration — все проекты имеют одинаковую структуру, вследствие чего новым разработчикам (которые знают maven) очень легко подхватить любой проект.
+1
все очень просто решается с помощью maven-antrun-plugin.
maven приучает к порядку при сборке. танцы с бубном зависят от требований по сборке.
maven приучает к порядку при сборке. танцы с бубном зависят от требований по сборке.
0
assembly plugin, не?
+1
копирование решается использованием maven-ant-plugin (если не хватает более подходящих вещей, заточенные на конкретные типы сборки, вроде maven-assembly-plugin)
0
вы просто не умеете его готовить.
если вам надо скопировать файлы ресурсов, то есть теги 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
0
Я тут как-то написал псто на эту тему. Был молод и неумён, но предпоследний раздел вроде отвечает на ваш вопрос.
0
Сам работал когда-то с Антом. Как только начнутся многомодульные проекты + сложные библиотечные зависимости — Ант можно выбрасывать и брать Maven.
+2
Управление зависимостями — это основное преимущество мавена. Мавен устроен по принципу 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>
+3
А Вы пробовали сделать шаг в сторону в Gradle?
В maven это выливается в 10 минут на сочинение правильного запроса к гуглу. Найденное решение не всегда блещет элегантностью, но оно есть.
В Gradle это выливается в 4-6 часов чтения его исходников и реверсинжиниринга DSL. Причина: документация далека от исчерпывающей, DSL не консистентен, а тул не настолько популярен, чтобы находились готовые рецепты. Рассылка завалена вопросами вроде «как сделать то?» и «я тут попробовал ваш рецепт и призвал сатану».
В maven это выливается в 10 минут на сочинение правильного запроса к гуглу. Найденное решение не всегда блещет элегантностью, но оно есть.
В Gradle это выливается в 4-6 часов чтения его исходников и реверсинжиниринга DSL. Причина: документация далека от исчерпывающей, DSL не консистентен, а тул не настолько популярен, чтобы находились готовые рецепты. Рассылка завалена вопросами вроде «как сделать то?» и «я тут попробовал ваш рецепт и призвал сатану».
+5
Я пробовал.
Да, тул не настолько популярен, чтобы были готовые рецепты на все случаи жизни. Да, по-моему, где-то в самом начале пришлось таки залезть разок в его исходники :). Да, документация оставляет желать…
Но сама возможность писать на человеческом языке вместо хардкорных иксэмэльных портянок лично для меня перевешивает :)
Да, тул не настолько популярен, чтобы были готовые рецепты на все случаи жизни. Да, по-моему, где-то в самом начале пришлось таки залезть разок в его исходники :). Да, документация оставляет желать…
Но сама возможность писать на человеческом языке вместо хардкорных иксэмэльных портянок лично для меня перевешивает :)
+2
НеБ я не пробовал. А это что-то бОльшее, чем билдер мавеновских конфигураций? Я из поверхностного лазанья по сайту не смог это сходу понять…
0
По замыслу это заменяет «хардкорные иксэмэльные портянки» на удобочитаемую конфигурацию в виде Groovy кода
0
Понятно, значит я правильно понял. В этом есть свои преимущества, но есть и недостатки. Как, впрочем, и везде :). Останусь на gradle, проекты у меня небольшие и проблема со вхождением новых участников, привыкших к мавену и не могущих переучиться, в проект не стоит остро. Ну, и «плюс пара проектов» на gradle в мире послужит его популяризации :)
0
НЛО прилетело и опубликовало эту надпись здесь
Вопрос не в тему: а вы с Firebird в Java через ORM работаете?
0
Спасибо за то, что рассказали про buildnumber-maven-plugin. Как-то он раньше проскользнул мимо меня, но как раз есть где его применить.
+1
Мы сделали вот так сборку 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.
0
вся портянка про «Далее требовалось перед сборкой в jar-архив скидать все ресурсы (картинки и .properties-файлы) в директорию со скомпилированными .class-файлами.» не нужна, если ресурсы положить в scr/main/resources вместо src/main/java — Maven тогда сам сделает именно то, что вы «навелосипедили» (он даже сам догадается не фильтровать картинки)
0
Люди, милые мои, ну как, как при живом gradle вас заносит начинать новые проекты на maven? что-ж это за мазохизм-то такой?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От велосипеда к Maven