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

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

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

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

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

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

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

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

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

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

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

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

maven 3.x уже встроен в IDEs (по крайней мере, на 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 через плагин AntRun Maven, и мы также написали наши собственные плагины Maven. Это, кстати, занимает несколько минут и сводится к написанию аннотированный POJO-объект.

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

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

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

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

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

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

в Lattice build файлы записываются не в 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 с Ivy может быть способом решения проблем зависимости для людей, которые действительно не хотят использовать Maven. Он решает 90% вещей, которые Maven должен был решить.