Maven или Ivy для управления зависимостями от Ant? - PullRequest
36 голосов
/ 25 ноября 2008

Мне было интересно узнать, как лучше управлять зависимостями проектов от ant. Каковы плюсы и минусы задачи Maven Ant и плюща?

Ответы [ 8 ]

41 голосов
/ 26 ноября 2008

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

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

40 голосов
/ 07 мая 2009

Муравей + Плющ == Палаточный лагерь, где люди используют объекты по мере необходимости.
Maven == Курорт, где вы полагаетесь на кого-то другого для предоставления услуг.

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

Ant + Ivy потребуется больше времени для запуска проекта, но если у команды есть опыт сборки / интеграции, они могут адаптировать систему сборки к тому, как они разрабатывают и выпускают код.

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

Удивительно, что и Ant, и Maven выбирают XML в качестве языка для выражения рецептов сборки. Сообщество Java застряло на этом XML ...

8 голосов
/ 04 мая 2010

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

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

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

Spring Framework использует Ivy в процессе сборки. Я думаю, что это можно расценивать как вотум доверия Айви.

7 голосов
/ 18 января 2010

Я думаю, что это сообщение в блоге охватывает именно то, что ищет ОП:

Почему вы должны использовать задачи Maven Ant вместо Maven или Ivy

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

Если ваша долгосрочная цель - перейти на использование Maven для управления всем процессом сборки (что может быть сделано для новых проектов с нуля), то я настоятельно рекомендую использовать файлы Maven pom.xml для управления зависимостями от имени Ant файлы build.xml. Конечный результат заключается в том, что и ваши новые проекты, и ваши старые проекты используют один и тот же механизм для управления зависимостями. И оказывается, что Maven действительно лучше справляется с управлением зависимостями для файлов Ant build.xml, чем Ivy.

До принятия Maven в качестве нашего основного инструмента для сборки у меня была попытка разработчика использовать Ivy в сочетании с существующими файлами Ant build.xml. Это был самый неприятный опыт, который очень скоро заставил нас отказаться от Айви. Мы пошли на усыновление Maven. Наши новые проекты начали строиться с использованием стандартного подхода Maven и т. Д.

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

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

На самом деле с заданием Ant для Maven нет никаких жизненно важных причин для существования Ivy.

5 голосов
/ 26 января 2012

Сравнение Maven с ivy / ant - это сравнение смартфона и телеграфии.

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

Основным преимуществом Maven является «соглашение по конфигурации» (http://en.wikipedia.org/wiki/Convention_over_configuration) очень важная парадигма. Короче говоря, это означает, что вам не нужно знать / настраивать вещи, которые очевидны / тривиальны / обычны. Хотя Maven и все его плагины поставляются со многими настройками по умолчанию, у вас всегда есть возможность настроить свои проекты под ваши особые потребности. С Maven, с одной стороны, вы можете настроить проект очень легко и быстро, с другой - вы можете настроить Расширение проекта до ваших потребностей с минимальными усилиями. Если вы поняли ключевые концепции Maven, вы будете использовать каждый проект, а также проекты, которые также не являются типичными проектами разработки программного обеспечения.

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

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

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

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

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

А теперь вы похвалите следующее преимущество maven: вам нужно меньше документации о вашей конфигурации, потому что документация является частью каждого подключаемого модуля maven, который вы хотите использовать.

Так что, признаюсь, я был антагонистом Мавена.

2 голосов
/ 26 ноября 2008

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

1 голос
/ 10 апреля 2010

Я только что провел 2 дня, читая документацию по Ivy, и я должен сказать, ИСПОЛЬЗУЙТЕ MAVEN, если у вас есть какой-либо выбор. Насколько я могу судить, Айви полная и полная фигня. Я просто потратил впустую 2 дня, пытаясь включить его в свою сборку, и сейчас сокращаю свои потери. Почему?

  • Плющ - наполовину попытка управления зависимостями
  • Документация Ivy - полная шутка
  • Примеры плюща и учебник бесполезны

Как только я ввел «конфигурации» (читай как профили maven), Айви начала безумно загружать все виды мусора, которые мне не нужны, а затем терпела неудачу. Документация для Айви - полная шутка. Maven документация в сравнении читается как сон. Если вам нужен пример того, насколько непонятной и плохо написанной является документация Ivy, взгляните на справочную страницу для конфигурации . Это неотъемлемая часть любой сборки, но в Ivy они плохо продуманы.

...