Какие впечатления от Maven?

JavaPosse довольно подробно обсуждает Maven в недавний подкаст № 217. Консенсус заключался в том, что он очень ограничивает то, как он позволяет вам структурировать ваши проекты, но его использование растет, и что он может предлагать стандарт кросс-IDE для представления проекта.

Обновлять - Javaposse также провел информативную сессию на Java Roundup 09 прошлой весной под названием "Мавен с болью?" Я рассмеялся (с ужасающей симпатией), когда к концу записи один из участников рассказал, как обновление плагина сломало их сборку - за два дня до выпуск продукции.

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

Обновлять - для тех, кто испытывает иррациональное пренебрежение к моему иррациональному мнению, позвольте мне показать вам, что "maven" вызывает в моей голове:

Да, на мой взгляд, Edna Mode - это то воплощение "maven". И я не хочу, чтобы она была в моем составе - слишком властная!

Какое имя было бы лучше? Выдуманные слова лучше всего подходят для точных результатов поиска в Google. Для хорошего впечатления используйте настоящие слова с положительным оттенком.

Maven можно использовать для управления всем жизненным циклом вашего проекта от начала до развертывания. Если это то, что вам нужно, тогда Maven - правильный инструмент. Если вы просто ищете инструмент для управления зависимостями, вы можете также изучить Муравьиный плющ.

Он использовался в большинстве проектов, над которыми я работал, и ... хотя иногда и раздражал (конфигурации и документация), он сэкономил мне много времени. Большинство Java-проектов Apache используют Maven.

Независимо от того, работает ли Maven, это действительно зависит от того, что вы хотите, чтобы он делал для вас.

yc

Есть несколько очень хороших моментов в maven:

• Архетипы: своего рода стартовый (базовый) проект (очень полезный), который делают многие люди. В компаниях, где вы склонны воссоздавать одни и те же вещи снова и снова, это чрезвычайно практично.
• Управление зависимостями: вам действительно нужно попробовать, чтобы это понравилось. Плющ тоже хороший инструмент совместимый.
• Управление жизненным циклом: без всей IDE вы можете делать все из командной строки с помощью maven, я имею в виду: компилировать, упаковывать, тестировать, развертывать и т. д. И можно сделать один шаг зависимым от других. Хотя я думаю, что настройки по умолчанию не самые лучшие, эту часть можно настроить.

Кроме того, maven также может делать некоторые муравьиные вещи.

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

Я люблю Maven и постоянно им пользуюсь. Отчасти причина в том, что его очень просто настроить с помощью подключаемых модулей XML Eclipse (у него есть XSD, который очень информативен). Maven также отлично подходит для управления зависимостями, поскольку он позволяет загружать jar-файлы из репозиториев и исключать транзитивные зависимости, где это применимо. Он также имеет встроенную цель site: site, которая отлично подходит для создания веб-сайтов проектов с соответствующими отчетами.

Maven отлично подходит для проектов, которые только начинаются, но у него есть ожидаемый формат вашего исходного кода. Если вы начнете свой проект с Maven, зная, что он может делать немедленно, это вам очень поможет. Но вы обязательно должны изучить это. «Из коробки» maven может делать отличные вещи, и для этого существует множество плагинов. Тем не менее, некоторые вещи ANT обрабатывает лучше, чем Maven, и если для него нет плагина Maven, это может быть трудно справиться в Maven. Но вы всегда можете научиться создавать свой собственный плагин Maven.

См. Лучшие сборки с Maven для хорошего руководства по maven.

О, и эти комментарии относятся к Maven 2, я никогда не использовал Maven 1.

@ MetroidFan2002: Maven 1 устарел и, возможно, более стабилен, чем Maven 2 (хотя и с меньшим количеством функций). Написание сценария Jelly - определенно плохая идея.

yc

Для проекта с открытым исходным кодом Maven имеет некоторые преимущества, особенно для ваших участников (например, mvn eclipse: eclipse).

Если вы выберете Maven, единственное правило, которому вы должны неукоснительно следовать: не боритесь с инструментом. Разместите свой проект именно так, как рекомендует Maven, соблюдайте все его соглашения и лучшие практики. Каждая маленькая битва, в которую вы вступаете с Maven, - это день, когда вы не будете тратить время на написание кода для своего проекта.

Также заранее продумайте, где вы хотите развернуть свои артефакты (собираетесь ли вы разместить свой собственный репозиторий?).

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

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

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

Я использую Maven для работы с открытым исходным кодом, потому что он относительно быстро создает разумный веб-сайт. Это то, что редко интересует разработчиков, не занимающихся открытым исходным кодом. Даже с этой задачей я часто тратил много времени, пытаясь понять, почему что-то работает не так, как ожидалось. Для работы с открытым исходным кодом я обычно использую ant для создания сборки (jar), поскольку это надежно.

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

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

1) maven решает 90% общих проблем, но если вы боретесь с остальными 10%, возиться с ними всегда беспорядочно.

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

3) мы будем бороться трудно, но в конце концов мы отказались: мы используем муравей из Maven. Иногда мы используем даже ant для вызова maven. Теперь даже не пытайтесь думать, что мы - отстой: если бы вы только могли видеть сложность определенных шагов в нашем процессе сборки ... просто maven чаще всего мешает вам при создании сложных проектов.

4) управление локальным репозиторием является обузой. Артефактура не годится. И другие подобные товары.

В общем: я бы предложил Ant (может быть, с Ivy, если вы хотите управлять зависимостями, но я никогда этого не пробовал)

Пока Стефано

Я имел несчастье работать с Maven, когда он переходил с 1.x на 2.x. Это в значительной степени занимало 100% времени одного из наших старших членов команды. В конце концов мы его списали.

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

Наряду с плагином m2eclipse для eclipse управление зависимостями становится пустяком - у него есть отличный инструмент визуализации зависимостей.

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

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

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

Maven также ужасен тем, что помогает вам диагностировать проблемы, когда он не работает. А сценарии сборки - это нечитаемые блинчики неинтуитивного и неестественного xml, который, конечно, может быть тем, что вы предпочитаете и ищете (если у вас есть муравейник).

Я люблю maven. Maven полон добра и обещаний. Я также ненавижу maven.

Редактировать:

О, и плагин maven для eclipse просто великолепен.

У Мэтта Рейбла есть запись в блоге http://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jason.

Я слышал, что большинству людей, использующих maven, это не нравится.

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

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

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

РЕДАКТИРОВАТЬ: Я забыл добавить, что даже если вам не нравится Maven, вы не можете его игнорировать. Если вы пишете библиотеки с открытым исходным кодом, которые используют другие люди, они будут ожидать, что они будут доступны в репозитории Maven, чтобы они могли легко использовать их из своих сборок Maven.

РЕДАКТИРОВАТЬ2: Поскольку вы пояснили, что ваш основной интерес заключается в предоставлении библиотеки с открытым исходным кодом другим пользователям Maven, стоит отметить, что вам не обязательно использовать Maven для достижения этой цели. Есть набор задач Ant для публикации в репозитории Maven. Итак, если вы хотите продолжать использовать Ant для сборки своего проекта, вы можете это сделать, но все равно удовлетворить пользователей, использующих Maven.

Мне лично очень нравится Maven, и многие другие тоже. Maven2 имеет гораздо лучшую репутацию, чем Maven1, и, похоже, в сообществе OSS есть тенденция к нему. Для магазинов, у которых есть много разных проектов, это действительно помогает создать единообразие, и вы не чувствуете, что изобретаете велосипед заново с помощью скриптов Ant для каждого проекта.

Чтобы ответить на ваш вопрос, было бы хорошо, если бы вы хотя бы отправили свой jar в центральный репозиторий. Вам не нужно заменять существующий процесс сборки на maven, но вам нужно будет хотя бы поддерживать POM с зависимостями для вашего проекта.

http://maven.apache.org/guides/mini/guide-central-repository-upload.html

Это принесет пользу вашему проекту, так как пользователям (которые используют Maven или Ivy) будет намного проще загрузить и установить ваш jar.

Если вы решите использовать maven для сборки, это, скорее всего, увеличит участие в вашем проекте, потому что это несколько снизит входной барьер. После того, как вы создали свой проект с использованием maven, все, что требуется от кого-то, кто хочет собрать из исходников, - это запустить «mvn install». (FWIW, в некоторой степени то же самое можно сделать с помощью Ant / Ivy).

Некоторые друзья сказали мне, что Maven чем-то похож на NetBeans: оба страдают определенным клеймом, которое когда-то было заслуженным, но теперь уже не совсем актуально. Я ненавидел Maven 1.x из-за отсутствия документации и из-за XML / Jelly.

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

И POM, и управление зависимостями - отличные идеи, но возникает вопрос, будут ли они ассимилированы более новым инструментом, точно так же, как C++ проложил путь к новым языкам.

Последнее замечание: дихотомия между Ant и Maven несколько ложна. Gradle и Gant - это инструменты сборки в пространстве Groovy, которые могут многое предложить даже для простых проектов Java. Поскольку они используют Groovy, простые задачи действительно просты (в отличие от болезненных конструкций XML в Ant); тем не менее, они имеют сильную интеграцию с Ant, поэтому существует богатый набор «сложных» задач.

У нас есть сообщество разработчиков с открытым исходным кодом, которые независимо работают над своими собственными проектами. Некоторые из этих проектов используют библиотеки из других проектов. Без управления зависимостями мы сталкиваемся с циклическими зависимостями в jar-файлах. ant не помогал с этими проблемами (это было до Ivy, которым я не пользовался). Используя maven и развертывая jar-файлы, нам удается уменьшить зависимости и получить намного меньше проблем. Таким образом, мы получили огромную пользу от наличия инструмента управления зависимостями, и лично я обнаружил, что усилия по использованию maven того стоят.

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

Документация улучшается, а m2eclipse просто потрясающий. Но кто-то выше указал на статью о «нарушении конструкции». Он сделал несколько хороших замечаний. Хотя я лично считаю, что maven - лучший инструмент, чем ant, в конечном итоге наш опыт сделает maven3 лучшим инструментом, чем maven2.

Я не мог без этого жить. Я могу зайти на ЛЮБУЮ машину в мире с подключением к Интернету, JDK и Maven 2, проверить свой репозиторий git и запустить mvn test, и он будет построен. Смею вас, сказать это о любом другом инструменте сборки. :-)

Основным преимуществом использования Maven является то, что он экстернализирует «объектную модель проекта» (отсюда и pom.xml). Преимущество такой независимой структуры проекта заключается в том, что он становится переносимым между инструментами и IDE.

Все основные IDE вложили много средств в поддержку maven. Когда вы открываете проект в вашей IDE по выбору, он принимает структуру Maven, и вы готовы к работе:

• В Затмение: Импорт ... Проект Maven ...
• В IntelliJ: откройте проект ... перейдите к pom.xml
• В Netbeans: Все прозрачно

Обычно вы помещаете все Метаданные IDE (.iml, .project, .classpath и т. д.) В Список игнорирования VCS.

Очевидно, что движки непрерывной интеграции выигрывают аналогичным образом от подхода, основанного на POM.

Есть кривая обучения и ограничения, но вы получите много взамен.