Должен ли я перейти от Ant к Maven?

Ответ 1

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

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

Ответ 2

Вы прочитали главу 1 "Maven, окончательное руководство"? В частности, 1.7 Сравнение Maven с Ant имеет интересное обсуждение.

Я согласен с другими ответами, которые советуют соблюдать осторожность. У Maven есть сильные стороны, но ничего, что нельзя сделать с помощью процесса сборки Ant:

• Управление зависимостями: Ant имеет подпроект Ivy, который может взаимодействовать с репозиториями Maven.

• условная конфигурация: вы также можете сделать это с помощью Ant, это просто вопрос установления правил и их принудительного применения.

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

• Повторное использование логики сборки (плагины Maven): вы также можете достичь этого в Ant с помощью macrodef и библиотек задач.

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

Лично я увижу, насколько хорошо существующий процесс решает вышеперечисленные проблемы: как управляются зависимости, есть ли центральный репозиторий? Являются ли структуры проекта едиными (когда я проверяю проект, который я не знаю, сколько времени требуется, чтобы выяснить, как его построить)? Есть ли какая-то форма повторного использования логики сборки, или каждый проект изобретает колесо? Какие из этих функций необходимы?

Затем я попытался бы сбалансировать затраты на добавление недостающих функций в существующий Ant script, против стоимости перехода на Maven (если вы не знаете Maven, это также включает стоимость изучать его).

В любом случае, я предлагаю вам создать небольшой прототип Maven (от 5 до 10 проектов), иллюстрирующий общие случаи в вашей сборке. Вы можете протестировать множество функций Maven с фиктивными проектами, содержащими небольшую логику Java (используйте плагин архетипа для их создания).

Ответ 3

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

Теперь, когда Maven на месте, мы полагаемся на хранилища артефактов для хранения этих версий, и мы разрешаем нашим объявлениям зависимости pom.xml быть официальным средством определения зависимостей версий. Это оказалось упрощающим подходом, который значительно упрощает разработку организации проекта в хранилищах управления версиями (и их проектах по строительству Hudson). Наш локальный репозиторий артефактов находится под резервной политикой вместе с нашими репозиториями управления версиями. Приятно использовать инструменты Maven для поиска и поиска нужной версии библиотеки. Мы также используем родительские pom файлы для определения зависимостей, которые по-прежнему наследуют другие poms проекта. Поэтому, если вы хотите, чтобы все проекты использовали одну и ту же версию log4j, это указано в одном месте в родительском pom файле. (Но любой проект может в любое время переопределить и указать конкретную версию вместо того, чтобы просто принимать значение по умолчанию от родительского помпа.)

Вот секрет успешного принятия Maven:

• Использовать подход построения проекта Maven для ваши новые проекты в области новых проектов
• Изменить существующие проекты, которые используйте файлы ant build.xml для включения задачи Maven для управления зависимостями (гибридный подход)

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

Хорошая вещь о задаче Maven для ant, где вы указываете все зависимости в файле pom.xml, заключается в том, что она включает только скромную модификацию существующего файла ant build.xml, чтобы включить Maven для этого. С точки зрения файла ant Maven является всего лишь средством определения определений классов, которые впоследствии используются в различных задачах сборки ant.

Классификатор зависимостей Maven может быть использован при определении классов классов, так что для компиляции можно установить подходящий путь к классам, используя unit test, packaging, et al. Другие определения в pom также можно получить в виде определений свойств ant.

Многие существующие файлы сборки ant довольно сложны. Это может быть огромным делом для преобразования таких проектов в полный процесс сборки Maven. Этот гибридный подход, заключающийся в том, что Maven управляет всеми зависимостями и оставляет основную часть файла ant build.xml как есть, является наиболее прагматичным.

Ответ 4

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

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

С другой стороны, если вы хотите использовать сервер непрерывной интеграции, такой как hudson или репозиторий артефактов, например nexus, то перемещение вашего проекта в maven может действительно помочь в эффективности сборки и автоматизации. Вероятно, вам понравится maven в таких ситуациях, потому что полный цикл от зависимости для сборки до артефакта может быть достигнут с использованием этих типов инструментов, и вы сможете лучше контролировать свои сборки и релизы. В моем текущем проекте у нас много модулей и зависимостей, как вы упомянули. Миграция на maven, чтобы мы могли использовать hudson и nexus, действительно помогли, потому что мы могли отбросить все эти сторонние банки в репозиторий nexus и перестать проверять их на контроль версий или отправлять их по электронной почте. Кроме того, сборки были из-под контроля, потому что люди CM имели план сборки в качестве документа, который они иногда выполняли, но при этом часть вашего проекта (то есть pom.xml) определяет, как вы должны строить, и позволяет вам применять Это. Maven - это клей, который держит все эти вещи вместе.

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