Buildr, Gradle или дождаться Maven 3?[закрыто]

Question

Я действительно устал постоянно бороться с Maven 2.Инструменты сборки не должны мешать.Недавно я смотрел на Buildr и Gradle.Maven 3, кажется, исправляет некоторые проблемы.Итак, на что мне идти сейчас?Строитель?Грейдл?Или подождать год Maven 3?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Итак, часть моей сборки — это разархивировать этот файл и поместить его в войну.Легко сделать в 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.

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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