Maven или Ivy для управления зависимостями от Ant?

Ответ 1

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

Действительно, с задачей Ant для Maven нет жизнеспособной причины для существования Айви.

Ответ 5

Я думаю, что это сообщение в блоге точно отражает то, что ищет OP:

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

Ответ 6

Сравнение Maven с плющом / ant заключается в сравнении смартфона с телеграфией.

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

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

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

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

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

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

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

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

Итак, я признаюсь, что был антагонистом Maven.

Ответ 7

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

Ответ 8

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

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

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