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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому я бы придерживался maven 2.x для производственных сборок и играл с maven 3.x для разработки.

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

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

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

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

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

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

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

Попробуйте https://github.com/hackingspirit/Lattice Lattice. Я автор. Вот совок:

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

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

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

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