Buildr, Gradle или ждать Maven 3?

Ответ 1

Никакая система сборки не является волшебной пулей. Я нахожу, что Maven решает больше проблем, чем для меня, но я вполне комфортно пишу плагины, чтобы обойти его недостатки, я также занимаюсь сотнями проектов, поэтому наследование Maven и обработка зависимостей мне очень полезны.

Просмотрите SO немного, и вы увидите, что Buildr и Gradle имеют проблемы тоже (одинаковые для Ant и Ivy), как правило, вы торгуете одним набором проблем для другого и его случай нахождения наименее болезненный.

Есть ли что-нибудь в частности, которое беспокоит вас о Maven или это общий зуд? Если это особая проблема, стоит обратить внимание на проблемы Maven 3 на Jira, если проблема не решена, вы можете ее поднять, или еще может быть мало смысла в ожидании

Ответ 2

Я не ожидал бы слишком многого от Maven 3. Люди, стоящие за родословной сборки Maven, всегда придерживались предположения, что сборки проекта являются однородными, то есть: все проблемы сборки в основном сводятся к одной и той же проблеме. Этот взгляд на мир можно проводить довольно последовательно перед лицом противоположных взглядов, но он стоит дорого. Отсутствие логики сценариев в Maven ( "когда вы хотите, чтобы script вы знаете, что что-то не так" ), громоздкий API-интерфейс плагина ( "обычный пользователь Maven должен писать плагин" ) и центральный репозиторий ( "все мы имеем одинаковые зависимости" ) - все это заветы этого всеобъемлющего предположения.

В реальных задачах построения проблемы неоднородны, потому что люди строят программное обеспечение по самым разным причинам. Они все "развиваются", как и все "сверлят дыры" время от времени для решения уникальных проблем. Независимо от вашего уровня абстракции вы всегда найдете сходство при сравнении произвольных проблем сборки. Это почитание этих сходств и осуждение различий, что является падением для дизайна Maven и причиной того, что он рисует так много флагов. В принципе, Maven является авторитарным и утопическим в своем мировоззрении.

PS: у Maven есть хорошие возможности, такие как условная конфигурация и идея использования репозиториев (реализация Maven этой идеи затруднительна).

Ответ 3

Мы используем Maven здесь, но я обнаружил, что, когда вы выходите за рамки простого проекта, pom.xml начинает становиться все более сложным. Вы начинаете тратить много времени на разработку того, как в настройке вашего pom делать то, что вы хотите, и как обойти различные проблемы.

То, что действительно меня достало, было ухом, которое мы строим. У нас есть несколько войн в этом ушном файле, и Maven обычно хранит библиотеки в войнах. Однако, чтобы уменьшить размер войн и сохранить все банки, мы хотели поместить банки, разделяемые между войнами в каталоге уха lib.

К сожалению, Maven не справляется с этим очень хорошо. Нам нужно было вручную настроить это для каждого из войн войн, а затем добавить все эти зависимости в ухо pom.

В другом проекте мы имеем файлы справки на основе HTML. Люди, которые пишут помощь, пишут их в Microsoft Word, а затем используют программу для перевода их в HTML. Изменение одного символа может отражать сотни файлов.

Чтобы обойти эту проблему, наша справочная система хранится в нашем исходном репозитории как один заархивированный файл. Когда наша команда документации создает новый набор файлов справки, они застегивают ее и заменяют то, что находится в репозитории.

Итак, часть моей сборки распаковывает этот файл и помещает его в войну. Легко сделать в Ant, не может сделать это в Maven, если вы не используете плагин Antrun, который позволяет вам писать код Ant для обработки проблем, которые Maven не может обрабатывать без полноценного плагина.

Я вижу, что делает Maven, но теория опередила реальность. Я обнаружил, что Ivy и Ant могут выполнять большую часть проверки зависимостей, которую делает Maven без всех проблем написания и поддержания попов.

Если вы еще не используете Maven, сначала попробуйте Ant с Ivy. Затем, когда выйдет Maven 3, попробуйте это. Я помню переход от Maven 1 к Maven 2. Они были совершенно несовместимы друг с другом, и все, что вы узнали, используя Maven 1, было устаревшим. Было бы глупо учиться и переделывать ваши проекты в Maven 2, чтобы внезапно переделать все для Maven 3.

Ответ 4

maven 3.x уже встроен в IDE (по крайней мере, в netbeans, проверьте эту ссылку для получения дополнительной информации). Вы можете играть сегодня с maven 3.x, просто создавая проект Maven с netbeans.

Еще одна приятная новость заключается в том, что maven получила более "корпоративную" поддержку с интеграцией EJB/WS в проектах IDE (опять же, по крайней мере, на netbeans).

Итак, я буду придерживаться maven 2.x для создания сборки и игры с maven 3.x для разработки.

Ответ 5

Maven 2 и 3 отлично работают для меня в самых разных проектах. В настоящее время я использую Maven 3 alpha 7, который работает очень хорошо, особенно в сочетании с плагином Eclipse Maven.

Maven легко интегрируется с Ant - в обоих направлениях. В моем текущем проекте мы вызываем Maven из Ant несколько раз, чтобы выполнить сложный интеграционный тест. Аналогично, мы используем Ant через плагин Maven AntRun, и мы также написали наши собственные плагины Maven. Это, кстати, составляет несколько минут и сводится к написанию аннотированного Pojo.

Maven получает много флаков, потому что многим разработчикам не нравятся правила или соглашения. Проще говоря, никто не заставляет вас использовать Maven. Если вы хотите получить максимальную свободу - любыми способами - перепишите свой собственный процесс сборки для каждого проекта, к которому вы присоединяетесь. Однако, если вам нравится создавать программное обеспечение, а не повторно изобретать колесо с пользовательским процессом сборки в каждом проекте, перейдите на Maven.

Ответ 6

Сохраняйте ваш код в хорошем состоянии и разбиты на хорошо определенные модули, а перенос между системами сборки становится второстепенной проблемой.

На данный момент maven-2 является хорошим выбором для средних 2/3 проектов. Для действительно простого, ant все еще в порядке. Для действительно сложного, гибрид maven-2 и других инструментов (например, antrun) становится неизбежным.

Не уверен, почему у вас проблемы с maven-2.

Он отличается от ant и buildr тем, что он является инструментом для описания вашего процесса сборки, а не скриптингом. Сложные сборки, которые с несколькими динамическими частями и вложенными и/или временными зависимостями трудно построить, потому что их сложно описать.

Ответ 7

Дайте Lattice https://github.com/hackingspirit/Lattice. Я автор. Вот совок:

В Lattice файлы сборки записываются не в XML, а на языке Python. Бенефиты намного лучше читаются и мощные строгие скрипты, поддерживаемые Python. Для многомодульных проектов. Решетка использует топологическую сортировку для определения правильного порядка построения каждого модуля. Также запланировано, что Lattice проанализирует зависимость модуля, чтобы определить, как можно компилировать модуль. Исходный код решеток очень скудный, в настоящее время он состоит из около 500 строк исходного кода Python.

Ответ 8

Я думаю, что люди, жалующиеся на Maven, должны потратить немного дополнительного времени на изучение доступных плагинов. В ответ на комментарии, жалующиеся на то, что Maven является жестким и затрудняет использование пользовательской логики сборки/обеспечивает мелкомасштабный контроль над процессом сборки - я бы порекомендовал заглянуть в плагин Ant для Maven (их действительно несколько, но здесь один: http://maven.apache.org/plugins/maven-antrun-plugin). Я с большим успехом настраивал Maven с ним на протяжении многих лет. В принципе, он позволяет вам запускать любую команду Ant как часть сборки Maven, и вы можете сделать почти что угодно с Ant;)

Ответ 9

Ant с Ivy делает то же самое управление зависимостями, что и Maven (на самом деле он использует инфраструктуру управления зависимостями Maven в целом, включая те же репозитории URL), но без всякого беспорядка конфигурации POM.

Ant с помощью Ivy может быть способом обработки проблем с зависимостями для людей, которые действительно не хотят использовать Maven. Он решает 90% вещей, которые предположил Maven.