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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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