Является ли Ant по-прежнему «основным направлением» для сборок Java?

14

Мы постепенно заменяли файлы пакетных команд (windows .bat), которые просто объединяли классы, скомпилированные в IDE для разработчиков, с более полными сборками Ant (т. Е. Получали из CVS, чистую компиляцию, jar, архив, электронную почту и т. Д.)

Я потратил много времени на изучение (и отладку проблем) с Ant, поэтому мне удобнее использовать его для этих задач. Но мне интересно, используется ли Ant так же широко, как это было, когда я только начинал учиться, или «мир перешел» к чему-то более новому (и, возможно, более гладкому). (Я начал видеть больше материалов для сборки Maven, которые я никогда не использовал, например.)

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

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

— Сэм Голдберг
источник

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

— Сэм Голдберг

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

Ant - это в основном сценарий оболочки в XML (и использующий команды Ant вместо команд оболочки).

— user253751

Муравей - невероятная трата времени. Даже когда Maven был ужасен, это был разумный выбор. Ant не может быть интегрирован в IDE, а проекты Java - это огромный беспорядок в файлах - вы тратите 30% своего времени, просто переходя от файла к файлу.

— Брайан Хант

@bryanhunt: в конечном итоге мы использовали Maven для всех новых проектов. Однако я не нашел хорошего способа для Maven создать пакет развертывания для приложений Java. (Это хорошо для копирования зависимостей, загрузки jar-файлов.) Большинство постов, которые я прочитал, посвящены тому, как это сделать, например, использовать плагин Ant. Поэтому я обнаружил, что использую Ant для подготовки окончательного вывода из Maven. И кажется, что это проще сделать в Ant, чем использовать плагин Maven Assembly.

— Сэм Голдберг

23

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

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

С Maven вы также получаете преимущество, заключающееся в отсутствии необходимости переносить двоичные зависимости (я говорю о jars) в вашей системе SCM. Множество других замечательных инструментов Java знают, как читать POM-файлы Maven (преимущество стандартизации), поэтому такие инструменты, как IDE, могут очень быстро настроить проект Maven, а инструменты сборки, такие как Jenkins, могут легко выполнять сборки Maven.

— Roņu
источник

13

Я также должен добавить, что использование Maven делает наши проекты независимыми от IDE, и если вы когда-либо были в магазине, где были войны IDE, вы можете по достоинству оценить устранение этой религиозной битвы!

— RonU

11

Я работал с Ant и Maven. По моему опыту, у Maven очень сильное преимущество над Ant.

Все проекты, которые я видел последние 2 или 3 года, похоже, используют maven. Около 3 лет назад это заставило меня задуматься, потому что используемые тогда maven версии (2.0.something) казались довольно ненадежными и глючными. Однако в какой-то момент (2.1 или 2.2 я не помню) maven стал надежным, и после некоторого времени, проведенного с ним, я передумал на противоположное. Теперь я предпочел бы удивиться, увидев кого-то, кто предпочитает муравья мавену.

Что касается менее положительного замечания о maven, мой опыт работы с его документацией был пока не таким большим. Я думаю, что видел продукт с документацией хуже, чем у maven, но я не могу вспомнить, какой именно (какая-то древняя библиотека CSV iirc).

— комар
источник

2

Не знаю, я нашел Maven Reference вполне приличным. Это не идеально, и темные углы недокументированы действительно, но все же ИМХО, это значительно лучше, чем в среднем.

— Петер Тёрёк

@ PéterTörök right Maven Reference - это и моя первая помощь. Хотя почему-то большинство вещей, которые меня беспокоят, заканчиваются этими темными недокументированными углами . Чтобы быть точным, я нахожу эти углы более «темными», чем «недокументированными» - я имею в виду, что я чувствую, что знания есть, но я не могу их расшифровать. Я не знаю, может быть, мне не повезло. Или, может быть, тупой. Или, может быть, парням из Maven просто не хватает достойного технического писателя в своей банде

— комнат

1

Почему, вы когда-нибудь видели проект с открытым исходным кодом, у которого был достойный технический писатель? ;-)

— Петер Тёрёк

@ PéterTörök так верно! :) Роскошь популярных проектов OSS заключается в том, что вокруг много «опытных парней», которые «заменяют» док-автора. Для меня это было в случае с Мейвеном - всегда был какой-то гуру, вокруг которого я мог спросить о хитрых вещах

— комнат

3

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

— TMN
источник

1

Я думаю, что муравей сам по себе мертв в воде; необходимость указывать все ваши зависимости classpath вручную (в зависимости от вашей настройки) слишком ручная и подвержена ошибкам. Если Ant используется вместе с инструментом управления зависимостями, таким как Ivy, он сохраняет свою силу и устраняет необходимость вручную управлять вашими зависимостями.

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

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

— Ричард
источник

0

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

Maven может быть новичком только на короткое время, но если это облегчает нашу работу, то стоит потратить время на обучение.

— Джон Шенкс
источник