Почему мавен? Каковы преимущества?
Каковы основные преимущества использования maven по сравнению, скажем, с муравьем? Кажется, это скорее раздражение, чем полезный инструмент. Я использую maven 2, с простым Eclipse Java EE (без m2eclipse) и tomcat.
Сторонники Maven считают, что
Maven позволяет легко получить зависимости вашего пакета
Maven заставляет вас иметь стандартную структуру каталогов
По моему опыту
Выяснить зависимости пакетов на самом деле не так сложно. Вы редко делаете это в любом случае. Вероятно, один раз во время настройки проекта и еще несколько во время обновлений. С maven вы в конечном итоге исправите несоответствующие зависимости, плохо написанные poms и все равно сделаете исключения пакетов.
Медленный цикл FIX-COMPILE-DEPLOY-DEBUG, который убивает производительность. Это моя главная неприятность. Вы вносите изменения, вам нужно ждать, пока не сработает сборка Maven, и дождаться ее развертывания. Никакого горячего развертывания вообще.
Или я просто делаю это неправильно? Пожалуйста, укажите мне правильное направление, я весь уши.
9 ответов
Выяснить зависимости пакетов на самом деле не так сложно. Вы редко делаете это в любом случае. Вероятно, один раз во время настройки проекта и еще несколько во время обновлений. С maven вы в конечном итоге исправите несоответствующие зависимости, плохо написанные poms и все равно сделаете исключения пакетов.
Не так сложно... для игрушечных проектов. Но у проектов, над которыми я работаю, их много, очень много, и я очень рад получить их транзитивно, чтобы иметь стандартизированную схему именования для них. Управлять всем этим вручную вручную было бы кошмаром.
И да, иногда приходится работать над сближением зависимостей. Но подумайте об этом дважды, это не присуще 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.
- Строго типизированный жизненный цикл. Существует строго определенный жизненный цикл, через который система программного обеспечения проходит от начала сборки до конца... и пользователям разрешено смешивать и сопоставлять свою систему с жизненным циклом, а не объединять их собственный жизненный цикл. это дает дополнительное преимущество, позволяя людям переходить от одного проекта к другому и говорить с использованием одного и того же словаря с точки зрения разработки программного обеспечения.
Винсент Массол
- Большой импульс: муравей теперь унаследован и не продвигается быстро. Maven быстро продвигается вперед, и у Maven есть множество ценных инструментов (CI, проект Dashboard, интеграция с IDE и т. Д.).
Выяснить зависимости для небольших проектов не сложно. Но как только вы начинаете работать с деревом зависимостей с сотнями зависимостей, все может легко выйти из-под контроля. (Я говорю из опыта здесь...)
Другой момент заключается в том, что если вы используете IDE с инкрементальной компиляцией и поддержкой Maven (например, Eclipse + m2eclipse), то вы сможете настроить редактирование / компиляцию / горячее развертывание и тестирование.
Лично я не делаю этого, потому что я пришел к недоверию к этому способу развития из-за плохого опыта в прошлом (до Maven). Возможно, кто-то может прокомментировать, действительно ли это работает с Eclipse + m2eclipse.
Maven - это один из инструментов, где вам нужно на самом деле заранее решить, что вам нравится, и хотите его использовать, так как вы потратите немало времени на его изучение, а принятое решение раз и навсегда позволит вам пропустить все виды сомнения во время обучения (потому что вам это нравится и вы хотите его использовать)!
Строгие соглашения помогают во многих местах - например, в Гудзоне, который может творить чудеса с проектами Maven - но поначалу это может быть трудно увидеть.
Изменить: Начиная с 2016 года Maven является единственным инструментом сборки Java, где все три основных среды IDE могут использовать источники из коробки. Другими словами, использование maven делает вашу сборку независимой от IDE. Это позволяет, например, использовать профилирование Netbeans, даже если вы обычно работаете в Eclipse.
Преимущества Maven над муравьями немало. Я пытаюсь обобщить их здесь.
Соглашение по конфигурации
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. Например, если вы новичок в проекте, вы все равно потратите больше времени на создание архитектуры проекта, объединение компонентов, кодирование, чем загрузка jar-файлов и копирование их в папку lib. Если у вас есть опыт работы в вашем домене, то вы уже знаете, как начать проект с каких библиотек. Я не вижу никакой пользы от использования Maven, особенно когда он создает много проблем при автоматическом "управлении зависимостями".
У меня есть только знания среднего уровня по maven, но я говорю вам, я делал большие проекты (например, ERP) без использования maven.