Почему maven? Каковы преимущества? [закрыто]

Каковы основные преимущества использования maven по сравнению, скажем, с ant? Кажется, это больше раздражает, чем помогает. Я использую maven 2 с простым Eclipse Java EE (без m2eclipse) и tomcat.

Сторонники maven считают, что

1. Maven позволяет легко получить зависимости вашего пакета

2. Maven заставляет вас иметь стандартную структуру каталогов

По моему опыту

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

2. Медленный цикл FIX-COMPILE-DEPLOY-DEBUG, убивающий производительность. Это моя главная проблема. Вы вносите изменения, вам нужно дождаться запуска сборки maven и дождаться ее развертывания. Никакого горячего развертывания.

Или я просто не так делаю? Пожалуйста, укажите мне правильное направление, я весь уши.

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

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

И да, иногда приходится работать над схождением зависимостей. Но подумайте дважды, это не присуще Maven, это присуще любой системе, использующей зависимости (и здесь я говорю о зависимостях Java в целом).

Таким образом, с Ant вы должны проделать ту же работу, за исключением того, что вам придется делать все вручную: получить некоторую версию проекта A и его зависимости, получить некоторую версию проекта B и его зависимости, выяснить, какие именно версии они используют, проверить чтобы они не пересекались, проверяя, что они не несовместимы, и т. д. Добро пожаловать в ад.

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

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

Медленный цикл FIX-COMPILE-DEPLOY-DEBUG, убивающий производительность. Это моя главная проблема. Вы вносите изменения, вам нужно дождаться запуска сборки maven и дождаться ее развертывания. Никакого горячего развертывания.

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

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

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

Maven можно рассматривать как полноценный инструмент разработки проекта, а не только как инструмент сборки, такой как Ant. Вы должны использовать Eclipse IDE с плагином maven, чтобы исправить все ваши проблемы.

Вот несколько преимуществ Maven, приведенных на странице Преимущества использования Maven :

Henning

• быстрая настройка проекта, никаких сложных файлов build.xml, просто POM и вперед
• все разработчики в проекте используют одни и те же зависимости jar из-за централизованной POM.
• получение ряда отчетов и показателей по проекту «бесплатно»
• уменьшить размер исходных дистрибутивов, потому что jar-файлы можно извлекать из центра.

Эммануэль Венисс

• доступно множество целей, поэтому нет необходимости разрабатывать какую-то конкретную часть процесса сборки, в отличие от ANT, мы можем повторно использовать существующие задачи ANT в процессе сборки с помощью плагина antrun

Джесси Макконнелл

• Способствует модульному дизайну кода. упрощая управление несколькими проектами, он позволяет разбить дизайн на несколько логических частей, объединяя эти части вместе с помощью отслеживания зависимостей в файлах pom.
• Обеспечивает модульный дизайн кода. модульному коду легко прислушаться, но когда код находится в отдельных проектах компиляции, невозможно перекрестно опылять ссылки между модулями кода, если вы специально не разрешите это в своем управлении зависимостями ... нет `` Я просто сделайте это сейчас и исправьте позже.
• Управление зависимостями четко заявлено. с механизмом управления зависимостями вы должны попытаться испортить управление версиями jar ... нет классической проблемы "какая это версия jar этого поставщика?" И установка его на существующий проект срывает вершину существующего беспорядка, если он существует, когда вы вынуждены создавать `` неизвестные '' версии в своем репозитории, чтобы все заработало ... или солгать себе, что вы знаете актуальная версия ABC.jar.
• строго типизированный жизненный цикл существует четко определенный жизненный цикл, который программная система проходит от начала сборки до конца ... и пользователям разрешается смешивать и согласовывать свою систему с жизненным циклом вместо того, чтобы строить свой собственный жизненный цикл. . Это дает дополнительное преимущество, так как позволяет людям переходить от одного проекта к другому и говорить, используя один и тот же словарь, в терминах создания программного обеспечения.

Винсент Массол

• Большой импульс: Ant теперь унаследовал и не продвигается вперед. Maven быстро продвигается вперед, и есть потенциал для использования множества ценных инструментов вокруг Maven (CI, проект Dashboard, интеграция с IDE и т. Д.).

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

Другой момент заключается в том, что если вы используете IDE с инкрементной компиляцией и поддержкой Maven (например, Eclipse + m2eclipse), вы сможете настроить редактирование / компиляцию / горячее развертывание и тестирование.

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

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

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

edit: По состоянию на 2016 год Maven - единственный инструмент сборки Java, в котором все три основные IDE могут использовать исходные коды из коробки. Другими словами, использование maven делает вашу сборку независимой от IDE. Это позволяет, например, использовать профилирование Netbeans, даже если вы обычно работаете в eclipse.

Преимуществ Maven перед ant довольно много. Я пытаюсь их здесь обобщить.

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

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

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

Что не так с maven?
Maven - это непросто. Цикл сборки (что и когда делается) не так ясен в POM. Кроме того, возникают проблемы с качеством компонентов и отсутствием зависимостей в публичных репозиториях.
Наилучший подход (для меня) - иметь внутренний репозиторий для кэширования (и хранения) зависимостей и применять его для управления выпусками компонентов. За проекты больше, чем примеры проектов в книге, вы поблагодарите maven до или после

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

Maven - это мощный инструмент управления проектами, основанный на POM (объектной модели проекта). Он используется для сборки проектов, зависимостей и документации. Он упрощает процесс сборки, как ANT. Но он слишком продвинут, чем ANT. Maven помогает управлять сборками, документацией, восстановлением, SCM, выпусками, распространением. - Репозиторий maven - это каталог упакованного файла JAR с файлом pom.xml. Maven ищет зависимости в репозиториях.

Я ни разу не сталкивался с пунктом 2? Можете ли вы объяснить, почему вы думаете, что это каким-либо образом влияет на развертывание. Во всяком случае, maven позволяет вам структурировать ваши проекты по модульному принципу, что фактически позволяет исправлять ошибки на определенном уровне и позволяет, например, независимую разработку API от остальной части проекта.

Возможно, вы пытаетесь втиснуть все в один модуль, и в этом случае проблема вовсе не в maven, а в том, как вы ее используете.

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

Все преимущества, упомянутые в других ответах, достижимы более простыми способами, чем с помощью maven. Если, например, вы новичок в проекте, вы все равно потратите больше времени на создание архитектуры проекта, объединение компонентов, кодирование, чем на загрузку jar-файлов и их копирование в папку lib. Если у вас есть опыт работы в своей области, то вы уже знаете, с каких библиотек начать проект. Я не вижу никакой пользы от использования maven, особенно когда он создает множество проблем при автоматическом "управлении зависимостями".

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