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


131

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

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

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

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

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

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

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

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


1
Меня действительно интересует пункт 2. Кто-нибудь еще замечает медленный цикл исправление-компиляция-развертывание? или все вроде как знают, но молчат об этом, так как maven - лучшее, что у нас есть / самая распространенная / самая крутая вещь. Создание войны / уха для развертывания - это уже плохо, maven делает еще хуже. На моем компьютере требуется примерно 5 секунд, чтобы просмотреть изменение jsp в проекте maven в разнесенной структуре каталогов? менее 1 сек. Я могу сохранять несколько раз, и он компилирует только последнее изменение на maven? каждое сохранение запускает сборку.
trix

Может быть, maven это не проблема, а поддержка / плагин IDE? Однако maven существует уже довольно давно, если мы не можем понять это правильно, должны ли мы двигаться / изобретать / предлагать что-то еще? кроме Айви
трикс

2
@Javid Хотя заголовок вопроса похож, суть вопроса отличается, ИМО, и я не считаю это обманом.
Паскаль Тивент,


На секунду это прозвучало так, будто вы говорили о NuGet ...
micahhoover

Ответы:


108

Выяснить зависимости пакетов действительно не так сложно. В любом случае вы редко это делаете. Вероятно, один раз при настройке проекта и еще несколько при обновлении. С помощью 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 года и никогда не оглядывался назад.


@Pascal, можешь сказать, какие инструменты ты используешь? IDE, плагины и т. Д. Вы говорите нам, что если я изменю файл .properties или файл jsp, он будет развернут без сборки maven? (возможно, «горячее развертывание» здесь не совсем правильный термин). Я не совсем понял, что имел в виду под муравьем. Я имел в виду использование стандартного взорванного каталога во время разработки и использование ant для создания war / ear перед выпуском. Для развернутого каталога правила просты: копируйте / компилируйте файлы из src в классы и не трогайте остальные.
trix

продолжение ... Однако в моих проектах то, что развертывается на tomcat, - это банки модулей. Если я изменю .jsp, разве maven не придется перестраивать эти банки?
trix

4
Согласитесь, большинство проектов - это игрушечные проекты, иначе говоря, простые зависимости. Это просто закон статистики.
trix

2
@trix, о горячем развертывании ant vs. maven: если вы не выполняете сборку ant для горячего развертывания, почему вы используете Maven для этого? Я думаю, если вы используете муравья для того же, это займет как минимум столько же времени ... не так ли?
Редди

2
Итак, Паскаль, не могли бы вы сказать нам, как у вас есть проект, настроенный на природу Maven, и не использовать процесс сборки для развертывания? Это пункт 2 исходного вопроса. Мне интересно, как это сделать, поэтому очень признателен, если вы можете дать нам четкое объяснение.

20

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 и т. Д.).

5
Во время голосования вниз укажите причину, это не сказано, но этическое правило для stackoverflow.
YoK

1
В ссылках нет ничего плохого, но вам действительно нужно дать понять, что контент не ваш.
Паскаль Тивент

Спасибо. Я обязательно процитирую его, а не просто укажу, откуда на него ссылаются. всего 30 с лишним дней в stackoverflow и все еще изучаю искусство :).
YoK

11

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

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

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


Можно начать с maven, чтобы получить все зависимости, а затем скопировать зависимости в свой проект, верно?
trix

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

Я имею в виду, что есть 2 проекта, единственная цель проекта maven - получить зависимости. Используйте контроль версий, чтобы отслеживать изменения между обновлениями зависимостей. Я все равно делаю это, чтобы увидеть изменения, если это сломает мою сборку.
trix

4
Ughh. Maven предназначен для использования не так. Одним из больших преимуществ Maven является отказ от проверки зависимых библиотек в системе контроля версий. С вашим подходом вы загромождаете свою VCS множеством версий множества двоичных файлов. А некоторые системы контроля версий особенно плохо справляются с обработкой двоичных файлов.
Stephen C

2
Как правило, вы узнаете на
горьком опыте, что

9

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

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

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


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

Противоположный? Ты имеешь в виду?
Thorbjørn Ravn Andersen

9

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

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

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

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

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


6

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


3

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


2

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

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


Я использую простой eclipse jee, maven 2 и tomcat. Очевидно веб-приложение. Если я изменяю файл свойств или jsp, чтобы увидеть свои изменения в tomcat, maven должен выполнить свою сборку, создать war / ear и развернуть его на tomcat. Это медленно по сравнению с использованием разнесенной структуры каталогов.
trix

1
@trix Hot deploy в Eclipse с Tomcat просто работает. Ты делаешь это неправильно.
Паскаль Тивент,

0

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.