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

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

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

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

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

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

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

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

Хеннинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Maven может обеспечить преимущества для вашего процесса сборки, используя стандартные соглашения и методы для ускорения вашего цикла разработки, в то же время помогая вам достичь более высоких показателей успеха. Более подробно о том, как Maven может помочь вам в процессе разработки, см. в разделе «Преимущества использования 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 года и никогда не оглядывался назад.