Должен ли я мигрировать из Ant в Maven? - PullRequest
10 голосов
/ 01 марта 2009

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

В Интернете много ресурсов, описывающих, как перейти с Ant на Maven, но я не нашел так много таких, которые объясняют почему: -)

Ответы [ 4 ]

20 голосов
/ 01 марта 2009

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

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

6 голосов
/ 02 марта 2009

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

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

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

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

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

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

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

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

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

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

3 голосов
/ 01 марта 2009

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

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

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

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

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

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

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

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

2 голосов
/ 01 марта 2009

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

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

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

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

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