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

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

Henning

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

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