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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

EDIT2. Поскольку вы разъяснили, что ваш основной интерес заключается в предоставлении библиотеки Open Source другим пользователям Maven, стоит отметить, что вам не обязательно использовать Maven для достижения этого. Существует набор Ant Задачи для публикации в репозитории Maven. Итак, если вы хотите продолжать использовать Ant для создания своего проекта, вы можете делать, но все равно удовлетворяете своих пользователей, использующих Maven.

Ответ 3

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

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

Maven также страшен, помогая вам диагностировать проблемы, когда он не работает. И скрипты сборки - это нечитаемые стяжки неинтуитивного и неестественного xml, которые, конечно же, могут быть тем, что вы предпочитаете и ищете (если у вас есть ant -vision).

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

Edit:

О, и плагин maven для eclipse близок к блестящему.

Ответ 4

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

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

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

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

Ответ 5

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

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

Кроме того, maven также может использовать материал ant.

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

Ответ 10

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

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

• В Eclipse: Импорт... Проект Maven...
• В IntelliJ: Открыть проект... перейти к pom.xml
• В Netbeans: все прозрачно

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

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

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

Ответ 11

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

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

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

YC

Ответ 12

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

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

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

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

4) управление локальным хранилищем - это бремя. Artifactory не очень хорошо. И другие подобные продукты.

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

Bye Стефано

Ответ 13

matt raible имеет запись в блоге http://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jason.

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

Ответ 14

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

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

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

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

Ответ 15

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

Ответ 16

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

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

Ответ 17

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

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

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

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

Ответ 18

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

YC