Почему у Maven такая плохая репутация? [закрыто]

99

В Интернете много говорят о том, насколько плох Maven. Я использую некоторые функции Maven уже несколько лет, и наиболее важным преимуществом, на мой взгляд, является управление зависимостями.

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

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

ПРИМЕЧАНИЕ. Это не попытка вызвать аргумент. Это попытка очистить FUD.

Дан
источник
29
Я никогда не слышал, чтобы кто-то плохо отзывался о Maven. Я обнаружил, что проекты с Maven намного продуктивнее, чем с Ant.
Тейлор Лиз,
2
Я согласен с Тейлором. Я не использовал Maven, но слышал, как многие люди высоко о нем отзываются. Этот вопрос очень похож на FUD.
Мэтью Флашен,
27
@Taylor, @Matthew, @victor: Я удивлен, что вы не видели некоторых тирадов Maven. Это очень спорный инструмент. Это настоящая любовь или ненависть. Некоторым нравится умение управлять зависимостями, и они обвиняют тех, кому это не нравится, в том, что они не понимают его, а некоторые люди видят только проблемы, которые могут возникнуть и возникают со сложными распределенными зависимостями, и решают, что это не стоит хлопот.
Дэн Дайер,
8
Maven не соблюдает принцип KISS. Попробуйте сделать что-нибудь, кроме mvn clean install, и у вас проблемы. С Ant вы можете делать все, что хотите, без боли.
TraderJoeChicago
4
Это всего лишь один анекдот, но переход от Maven к Ant привел к тому, что время инкрементальной сборки увеличилось с ~ 15 с до более чем 2 минут. В нашей команде вы не найдете много поклонников Maven.
Питер Браттон

Ответы:

141

Я заглянул в maven около шести месяцев назад. Мы начинали новый проект, и нам нечего было поддерживать. При этом сказано:

  • Maven - это все или ничего. По крайней мере, насколько я мог судить по документации. Вы не можете легко использовать maven как замену ant и постепенно внедрять более продвинутые функции.
  • Согласно документации, Maven - это трансцендентное счастье, воплощающее в жизнь все ваши самые смелые мечты. Вам просто нужно медитировать над руководством в течение 10 лет, прежде чем вы станете просветленным.
  • Maven делает ваш процесс сборки зависимым от вашего сетевого подключения.
  • У Maven есть бесполезные сообщения об ошибках. Сравните ant "Target x не существует в проекте y" с mvn "Invalid task 'run": вы должны указать допустимую фазу жизненного цикла или цель в формате plugin: goal или pluginGroupId: pluginArtifactId: pluginVersion: goal "Полезно, он предлагает мне запустить mvn с -e для получения дополнительной информации, что означает, что он напечатает то же сообщение, а затем трассировку стека для BuildFailureException.

Большую часть моей неприязни к maven можно объяснить следующим отрывком из книги Better Builds with Maven:

Когда кто-то хочет узнать, что такое Maven, он обычно спрашивает: «Что такое Maven?» И ожидает короткого, содержательного ответа. «Ну, это инструмент сборки или среда сценариев» Maven - это больше, чем три скучных, скучных слова. Это комбинация идей, стандартов и программного обеспечения, и определение Maven невозможно разделить на просто усвоенные звуковые фрагменты. Революционные идеи часто трудно передать словами.

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

Кевин Петерсон
источник
134
Тем, кто понимает Maven, объяснения не нужны. Для тех, кто этого не делает, никаких объяснений невозможно.
Apocalisp
35
Один из ваших маркеров неверен. -o - автономный режим, поэтому нет, он не делает процесс сборки зависимым от вашего сетевого подключения.
MetroidFan2002,
10
Я согласен с точкой зрения "все или ничего". Я видел, как многие люди тратят слишком много времени, пытаясь сохранить половину своего портфеля проектов в ant, а половину - в maven. После фиксации вы должны приложить усилия, чтобы преобразовать каждую часть вашего развертывания.
sal
14
@Apocalisp: Другими словами, единственные люди, которые понимают Maven, - это люди, которые его написали?
Powerlord
5
Maven - это все или ничего. Это неправда. Вы можете использовать maven для управления зависимостями и ничего больше, если хотите. Все, что требуется, - это один рабочий пример того, как использовать задачи Maven ant для чтения вашего файла pom и создания пути к классам ANT, содержащего все ваши зависимости.
Jherico
109
  • Это с самого начала накладывает на вас жесткую структуру.
  • Он основан на XML, поэтому его так же трудно читать, как и ANT.
  • Его отчеты об ошибках неясны и оставляют вас в затруднительном положении, когда что-то пойдет не так.
  • Документация оставляет желать лучшего.
  • Он делает сложные вещи легкими, а простые - трудными.
  • Поддержание среды сборки Maven занимает слишком много времени, что лишает смысла наличие единой системы сборки.
  • Требуется много времени, чтобы понять, что вы нашли ошибку в maven и не настроили что-то неправильно. И ошибки действительно существуют, и в удивительных местах.
  • Он много обещает, но предает вас как красивого и соблазнительного, но эмоционально холодного и манипулирующего любовника.
изб
источник
45
++ Он делает сложные вещи легкими, а простые - трудными. Это так правильно!
Мартин К.
8
«Это многообещает, но предает вас, как красивого и соблазнительного, но эмоционально холодного и манипулятивного любовника». хахахаха ... это очень похоже на тот мастер фонг из "Balls of Fury"
cesar
8
По пункту 2: элементы используются почти всегда, атрибуты - почти никогда, поэтому XML даже труднее читать, чем Ant!
Carl Smotricz
4
+1 за последнюю пулю. Ничто не делает мой день похожим на встречу с удивительной и веселой аналогией, которая настолько верна.
Adam
1
Документация неплохая, отличная.
HDave
96

Конечно, в прошлом я, конечно, мучился и стонал о maven . Но сейчас меня бы не было без этого. Я чувствую, что преимущества намного перевешивают любые проблемы. В основном:

  • Стандартизированная структура проекта.
    • При присоединении к проекту нового разработчика:
      • Когда вы говорите, что это проект Maven, разработчик знает макет проекта и знает, как собрать и упаковать проект.
      • Когда вы говорите, что это проект Ant, разработчику придется подождать, пока вы объясните больше, или ему придется просмотреть файл build.xml, чтобы во всем разобраться.
    • Конечно, с помощью Ant всегда можно навязать общекорпоративный стандарт, но я думаю, что чаще всего вам придется заново изобретать пресловутое колесо.
  • Управление зависимостями.
    • Не только с внешними библиотеками, но и с внутренними библиотеками / модулями. Обязательно используйте прокси-сервер репозитория Maven, например Nexus или Artifactory .
    • С Айви кое-что из этого можно сделать . Фактически, если все, что вам нужно, это управление зависимостями, вам, вероятно, лучше использовать Ivy.
  • Особенно в рамках проекта. Я счел весьма полезным выделять небольшие подпроекты, и maven хорошо с этим справляется. С муравьем намного сложнее.
  • Стандартизированное управление артефактами (особенно в сочетании с нексусом или артефактом )
  • Релиз-плагин замечательный.
  • Интеграция Eclipse и NetBeans неплохая.
  • Интеграция с Hudson великолепна. В частности, графики тенденций для таких вещей, как findbugs.
  • Это второстепенный момент, но тот факт, что maven по умолчанию встраивает такие детали, как номер версии, внутри jar или war (а не только в имя файла), чрезвычайно полезен.

Минусы для меня в основном:

  • Командная строка совершенно бесполезна. Это меня очень оттолкнуло.
  • Формат XML очень подробный. Я понимаю, почему это было сделано именно так, но читать все равно больно.
    • Тем не менее, у него есть XSD для удобного редактирования в IDE.
  • Поначалу сложно осознать это. Например, такие вещи, как жизненный цикл.

Я искренне верю, что стоит потратить немного времени на знакомство с maven.

Доминик Митчелл
источник
2
Я не особо возражаю против формата XML (Eclipse может позаботиться о большинстве утомительных частей), а инструкции по сборке для больших проектов в любом случае обычно неприятны и сложны. Например, вы по-настоящему не разбили голову о кирпичную стену, пока не попытались заставить GNU automake делать что-то, что ему не нужно…
Donal Fellows
2
IntelliJ также имеет отличную поддержку Maven.
Стивен Бенитес
1
О, посмотри разумный ответ с подробностями.
Тим О'Брайен,
80

Мой практический опыт работы с двумя крупными проектами показывает, что мы потратили 1000-1500 часов для каждого проекта на проблемы, связанные с maven, не считая 500-часовых усилий по переходу с maven 1 на maven 2.

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

Интеграция с Eclipse ужасна. (У нас были бесконечные проблемы с генерацией кода, например, когда eclipse синхронизировался с сгенерированным кодом и довольно часто требовал полной перестройки. Виноваты как maven, так и eclipse, но eclipse более полезен, чем maven и, скажем, emacs, поэтому затмение остается, и maven должен уйти.)

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

Структура проекта Mavens не совсем подходит для разработки с Eclipse, и время сборки в eclipse увеличивается.

Из-за проблемы генерации кода и синхронизации нам приходилось перестраивать с нуля довольно часто, сокращая ваш цикл кода / компиляции / тестирования до бесконечного цикла compile / websurf / sleep / die / code-cycle, отправляя вас обратно в 90-е и Время компиляции 40 минут.

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

Подводя итог, maven настолько далек от KISS, насколько это возможно. Кроме того, защитники, как правило, относятся к тому типу людей, которые празднуют свой день рождения, когда их возраст - простое число. Не стесняйтесь голосовать за меня :-)

оборота KarlP
источник
3
Я согласен с некоторыми из того, что вы говорите на самом деле, хотя я думаю, что наконец понял это правильно. Однако, чтобы получить то, что вы хотите, вы можете взглянуть на Ivy, еще не пробовал, но, похоже, он обеспечивает управление зависимостями в более структурированной среде Ant.
Newtopian
5
Итак, вы нашли хорошую альтернативу Maven?
Тило,
4
Интеграция с Eclipse по- прежнему ужасна. Несмотря на наличие обновленных плагинов, есть задачи maven, управляемые плагинами, которые завершаются неудачно с непонятными сообщениями об ошибках. Затем коллеги говорят мне перейти в командную оболочку и запустить ту же команду ... тогда это загадочно работает. Eclipse - зрелая среда, плагин maven сильно отстает.
Carl Smotricz
2
Существует фундаментальная разница в том, как Maven и Eclipse определяют, что такое проект. В Maven проект - это более или менее удобный способ организации исходного кода. Eclipse изначально разрабатывался так, чтобы вы могли работать над одним или несколькими более или менее несвязанными проектами одновременно. Более поздние (не всегда обоснованные) требования приводят к тому, что IBM злоупотребляет проектами как «модулями», с которыми eclipse справляется довольно плохо. Чтобы согласовать определения, во многих случаях проекты maven, вероятно, следует сопоставить с исходными папками eclipse. Однако, поскольку maven - отстой, зачем беспокоиться.
KarlP
3
Привет! Я оплакиваю тот факт, что в следующий раз я стану лучшим возрастом - 29 лет, а следующий возраст идеального куба - 64 года, а мой последний возраст идеального пентеракта будет 32 года ... но я активно не защищаю maven.
cwallenpoole
46

Maven великолепен. На мой взгляд, причина его репутации связана с крутой кривой обучения. (с которым я, наконец, близок)

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

оборота Cuga
источник
6
Это может быть в некоторой степени правдой, но я обнаружил, что использование интеграции Maven с Eclipse действительно помогает сократить кривую обучения для людей. m2eclipse.codehaus.org
Тейлор Лиз,
2
@Taylor, у меня было много проблем с плагином, особенно если вы используете какую-то другую версию Eclipse или не дай бог RAD. Однако я думаю, что дело идет к цели ...
Дэн
Я использовал его только с Eclipse 3.3, 3.4 и студией разработчиков JBoss и согласился, что есть некоторые незначительные неприятности (например, редактор POM плохо работает), но у меня не было никаких серьезных проблем.
Тейлор Лиз,
10
Меня беспокоит не кривая обучения. Это действительно не так уж и сложно понять. Моя проблема в том, что для больших (коммерческих) проектов вы получаете гораздо меньшую ценность, чем затраченные усилия. Хорошо, ваши проекты строятся. Круто, но затраты на потраченный человек-год, постоянные сбои при сборке из-за внешних факторов, 10 минут компиляции вместо 5 секунд и уродливое рабочее пространство eclipse - это того не стоит. Кроме того, за те же деньги вы можете более или менее нанять парня, который постоянно строит ствол вручную.
KarlP
8
@Karlp - ну, вы еще не до конца понимаете ... 1.) «сбои из-за внешних факторов» - вы должны создать репозиторий проекта, в котором вы храните все свои зависимости и который вы контролируете версиями. 2.) "10 минут компиляции вместо 5 секунд" - возможно, для начальной установки maven и первой сборки - maven загружает все необходимые ему зависимости плюс ваш проект - но регулярные сборки, которые вы делаете, чтобы пытаться создать свой собственный код, не должны быть загруженным - см. 1 - также автономный режим. 3.) «Уродливая рабочая область eclipse» - maven работает во всех основных IDE (NB, IntelliJ) и из командной строки.
Нейт,
24

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

Апокалисп
источник
3
Мы должны производить его массово и продавать всем злодеям с огромной прибылью!
Йоахим Зауэр
7
Нет! Maven нельзя использовать для получения прибыли. Его можно использовать только во зло.
Apocalisp
18

Плюсы:

  • Управление зависимостями. Вот уже несколько лет я и мои коллеги не загружаем и не управляем зависимостями вручную. Это огромная экономия времени.
  • IDE-независимость. Оказывается, все основные IDE, Eclipse, IDEA и NetBeans имеют приличную поддержку проектов Maven, поэтому наши разработчики не привязаны к одной конкретной IDE.
  • Командная строка. В Maven поддержка одновременных конфигураций IDE и командной строки является простой, что хорошо для непрерывной интеграции.

Минусы:

  • Придется инвестировать в изучение Maven. Что ж, надо это сделать. Хорошие новости, не всем в команде нужно учиться.
  • Документация. Раньше было проблемой, теперь, благодаря Sonatype и их книге ( http://www.sonatype.com/products/maven/documentation/book-defguide ), ситуация намного лучше.
  • Жесткость. Иногда бывает сложно и неприятно делать то, что вы хотите. Я бы посоветовал не драться и не заставлять Maven делать то, что у него получается лучше всего, простые сборки или когда доступно стабильное моджо. В других случаях мы прекращаем работу и выполняем какие-то действия либо с помощью задач Ant ( http://maven.apache.org/plugins/maven-antrun-plugin/ ), либо с помощью внешних программ. Мне больше всего нравится плагин Groovy ( http://groovy.codehaus.org/GMaven ).

Конкуренция:

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

Итог: все наши проекты выполняются с Maven уже несколько лет.

Саша О
источник
3
Ant не конкурирует с Maven. Ivy не конкурирует с Maven (он конкурирует с задачами Maven Ant). Maven - это больше, чем инструмент сборки + управление зависимостями. Период.
Паскаль Тивент,
18

Думаю, у него плохая репутация среди людей, у которых есть самые простые и самые сложные проекты.

Если вы создаете одну WAR из одной кодовой базы, это заставляет вас перемещать структуру проекта и вручную перечислять два из трех jar-файлов в файле POM.

Если вы создаете один EAR из набора из девяти прототипов файлов EAR с некоторой комбинацией пяти файлов WAR, трех EJB и 17 других инструментов, jar-файлов зависимостей и конфигураций, требующих настройки файлов MANIFEST.MF и XML в существующих ресурсах во время окончательной сборки; тогда Maven, вероятно, будет слишком ограничивающим. Такой проект превращается в беспорядок из сложных вложенных профилей, файлов свойств и неправильного использования целей сборки Maven и обозначения классификатора.

Так что, если вы находитесь в нижних 10% кривой сложности, это излишне. На верхних 10% кривой вы находитесь в смирительной рубашке.

Рост Maven объясняется тем, что он хорошо работает для средних 80%.

сал
источник
16

Мой опыт перекликается с разочарованием из-за многих постов здесь. Проблема с Maven в том, что он скрывает и оборачивает детали управления сборкой в ​​своем стремлении к максимальному автоматическому совершенству. Это делает вас почти беспомощным, если он сломается.

По моему опыту, любая проблема с maven быстро переросла в многочасовую охоту за кулисами через паутину вложенных файлов xml, как и в случае с корневым каналом.

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

предостережение: последний раз работал с Maven 2 года назад, теперь может быть лучше.

Стив Б.
источник
14

Как и Гленн, я думаю, что у Maven не плохая репутация, а смешанная. Я работаю в течение 6 месяцев, пытаясь перенести довольно большой проект на Maven, и это ясно показывает ограничения инструмента.

По моему опыту, Maven хорош для:

  • управление внешними зависимостями
  • централизованное управление сборкой (помп наследование)
  • множество плагинов для множества вещей
  • очень хорошая интеграция с инструментами непрерывной интеграции
  • очень хорошие возможности отчетности (FindBugs, PMD, Checkstyle, Javadoc, ...)

И у него есть проблемы с:

  • подход "все или ничего" (трудно медленно перейти на Maven)
  • сложные зависимости, межмодульные зависимости
  • циклические зависимости (я знаю, плохой дизайн, но мы не можем исправить 5 лет разработки ...)
  • согласованность (диапазоны версий не везде работают одинаково)
  • ошибки (опять же с диапазоном версий)
  • воспроизводимые сборки (если вы не исправите номера версий всех плагинов, вы не можете быть уверены, что получите ту же сборку через 6 месяцев)
  • отсутствие документации (по основам документ неплох, но примеров работы с большими проектами не так много)

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

Гийом
источник
12

Я хотел бы ответить на несколько жалоб, высказанных на этом форуме:

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

Это неправда. Большая победа Maven заключается в использовании его для рационального управления зависимостями, и если вы хотите делать это в maven, а все остальное делать в ant, вы можете. Вот как:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

Теперь у вас есть объект пути к классам с именем maven.classpath, который содержит все зависимости maven, определенные в файле pom. Все, что вам нужно, это поместить jar-файл maven ant tasks в каталог Ant вашего ant.

Maven делает ваш процесс сборки зависимым от вашего сетевого подключения.

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

Это с самого начала накладывает на вас жесткую структуру.

Неясно, относится ли это к формату файла или проблеме «соглашение или конфигурация». Для последнего существует множество невидимых значений по умолчанию, таких как ожидаемое расположение исходных файлов и ресурсов Java или совместимость источника. Но это не жесткость, это установка разумных значений по умолчанию для вас, чтобы вам не приходилось определять их явно. Все настройки можно довольно легко переопределить (хотя для новичка может быть сложно найти в документации, как изменить определенные вещи).

Если вы говорите о формате файла, ну, это рассматривается в ответе на следующую часть ...

Он основан на XML, поэтому его так же трудно читать, как и ANT.

Во-первых, я не понимаю, как вы можете жаловаться на то, что какой-то аспект чего-то «не лучше, чем муравей» служит оправданием плохой репутации. Во-вторых, хотя это все еще XML, формат XML гораздо более определен. Кроме того, поскольку он так определен, намного проще сделать разумный редактор толстого клиента для POM. Я видел страницы длинных скриптов сборки муравьев, которые прыгают повсюду. Никакой редактор сценариев сборки муравьев не сделает это более приятным, это просто еще один длинный список взаимосвязанных задач, представленных немного по-другому.

Сказав, что есть несколько жалоб, которые я видел здесь, которые имели или имели некоторую силу, самая большая из них

  • Документация плохая / отсутствует
  • Воспроизводимые сборки
  • Интеграция с Eclipse плохая
  • Ошибки

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

Проблема воспроизводимых сборок разбивается на две проблемы: диапазоны версий и автоматические обновления плагинов maven. Что касается обновлений плагинов, ну, если вы не убедитесь, что при пересборке проекта год спустя вы используете тот же самый JDK и ту же версию Ant, ну, это та же проблема с другим именем. Для диапазонов версий я рекомендую работать над плагином, который будет создавать временный pom с заблокированными версиями для всех прямых и транзитивных зависимостей и делать его частью жизненного цикла выпуска maven. Таким образом, ваши релизные сборки всегда будут точным описанием всех зависимостей.

Jherico
источник
11

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

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

солнце
источник
4
Я согласен с этим. Я думаю, что ценность управления зависимостями преувеличена. Конечно, это здорово, когда все работает, но при этом появляется несколько потенциальных точек отказа (не говоря уже о потенциальных дырах в безопасности). Вы можете настроить свой собственный сервер репозитория, чтобы несколько смягчить проблемы и заблокировать номера версий, чтобы избежать неожиданных обновлений, но я по-прежнему предпочитаю просто добавлять зависимости в систему контроля версий, поскольку они меняются не так часто, и это гарантирует повторяемую сборку. .
Дэн Дайер,
8

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


Это очень субъективный ответ, но вопрос в мнениях, так что ...

Мне нравится Maven, и чем больше я узнаю о нем, тем он нравится мне больше. Однако одно повлияло на мои чувства по этому поводу: сообщество maven в значительной степени сосредоточено вокруг Sonatype («компания maven», где работают многие из знатоков Maven), а Sonatype довольно агрессивно продвигает свои корпоративные продукты в сообществе.

Пример: Twitter-поток Maven Book ссылается на предполагаемое введение в управление репозиториями .

Извините, но это «вступление» - это половина информации, половина предложения Nexus. Популярная викторина: есть ли другие менеджеры репо, кроме Nexus и Nexus Pro? Кроме того, какое это имеет отношение к Maven Book с открытым исходным кодом? Ах да, глава об управлении репозиторием была выделена в отдельную книгу ... о Nexus. Ага. Если я внесу свой вклад в книгу Maven, получу ли я реферальную плату, если я увеличу продажи Nexus?

Представьте, что вы участвуете в форуме разработчиков Java, и было ясно, что сотрудники Sun, обсуждающие Java, собираются использовать любую возможность, чтобы поговорить о NetBeans и «NetBeans Pro». Через некоторое время он теряет чувство общности. У меня никогда не было такого опыта с Ant.

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

Зак Томпсон
источник
2
Зак, ты знаешь, мне было интересно, не хочешь ли ты узнать больше о Nexus Professional. :-)
Тим О'Брайен
7

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

Поль Сонье
источник
2
Я согласен с тем, что изначально людям может не хватать контроля, который у них был с Ant, но как только проект начнет принимать соглашения, которые навязывает Maven, они действительно увидят от этого повышение производительности.
Тейлор Лиз,
5
Неправда, Maven позволяет вам изменить структуру проекта, он просто предлагает структуру, которая широко используется.
adrian.tarau 03
3
Я не думаю, что это правда. Большинство жалоб на Maven связано с тем, как он может выйти из строя, насколько он медленный или с документацией. Я никогда особо не замечал, чтобы кто-нибудь жаловался на структуру.
Дэн Дайер
@ Дэн Дайер: Я поддерживаю это. На самом деле структура - одно из немногих достоинств Maven. Все остальное делает Maven таким ужасным.
Carl Smotricz
6

Слишком много магии.

Адам Яскевич
источник
3
Говорите конкретнее - что в этом такого волшебного, что не задокументировано?
whaley
4
Это волшебно, если вам нужно поискать в Интернете в течение 2 часов, чтобы узнать, почему что-то не работает должным образом. Если вам нужен конкретный пример: почему мой плагин не запускается? У вас есть 2 часа.
Дэмиен Би
На самом деле, всякий раз, когда я делаю что-то, что не связано с поиском в Интернете в течение 2 часов, я начинаю подозревать, что использую не тот инструмент для работы, или что я сильно неправильно понял / недооценил требования.
Дуг Москроп
6

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

Паскаль Тивент
источник
5

Единственная наиболее важная проблема для меня заключается в том, что Maven, если он неправильно настроен, может не создавать повторяющиеся сборки из-за:

  • ненадежные удаленные репозитории;
  • зависимости от плагинов и библиотек с версиями SNAPSHOT или без версий.

Сравните это со сборкой муравья, которая, несмотря на многословность и утомительность IMO, работает, поскольку все банки проверяются локально.

Хорошо то, что проблемы решаемы:

  • используйте свой собственный репозиторий maven, который стал мертвенно простым, я использую Archiva с хорошими результатами;
  • всегда правильно версируйте свои зависимости. Maven начал блокировать версии плагинов в супер-POM, начиная с 2.0.8 или 2.0.9, и все ваши зависимости должны быть от выпущенных версий.
Роберт Мунтяну
источник
+1 за ссылку на альтернативную реализацию репозитория.
Donal Fellows,
5

отличная идея - плохая реализация.

Недавно я переместил проект с Ant на Maven. В конце концов, это сработало хорошо, но мне пришлось использовать две разные версии maven-assembly-plugin и maven-jar-plugin в одном pom (было два профиля), потому что то, что работало в одной версии, было сломано в другой.

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

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

Я думаю, что разногласия возникают из-за того, что maven все еще развивается, и этот процесс иногда бывает болезненным.

С уважением

v.

vk
источник
Я согласен с тем, что идея лучше исполнения. Они выбрали нелегкую задачу для своей защиты, но я постоянно задаюсь вопросом, нельзя ли было сделать что-то более простым способом.
Eelco
5

Мне нравится maven. Я использовал его с версии до 1.0. Это мощный инструмент, который в итоге сэкономил мне много времени и улучшил мою инфраструктуру разработки. Но я могу понять разочарование некоторых людей. Я вижу 3 типа разочарования:

  1. где причины - реальные проблемы (например, подробные POM, отсутствие документации),
  2. некоторые из них являются дезинформацией (например, «для сборки вам необходимо подключение к Интернету» - неправда - нет, этого можно избежать),
  3. некоторые из них выпускаются в maven, но на самом деле виноват кто-то другой («не стреляйте в мессенджера»).

В первом случае настоящие проблемы - ну да, проблемы есть, POM многословны, документация могла бы быть лучше. Тем не менее, несмотря на это, с помощью maven можно быстро получить хорошие результаты. Я съеживаюсь каждый раз, когда получаю проект, созданный с помощью ant, и пытаюсь импортировать его в свою IDE. Настройка структуры каталогов может занять много времени. с maven это просто случай открытия файла POM в среде IDE.

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

Что касается последнего пункта, я думаю, что проблема транзитивных зависимостей maven, вероятно, является самым известным примером.

Транзитивные зависимости - это природа реального программного обеспечения, использующего повторное использование. Библиотеки DLL Windows, пакеты Debian, пакеты java, пакеты OSGi, даже заголовочный файл C ++ включает в себя все зависимости и страдают от проблемы зависимости. Если у вас есть две зависимости, и каждая использует разные версии одного и того же, вам нужно как-то попытаться решить эту проблему. Maven не пытается решить проблему зависимости, а, скорее, выводит ее на первый план и предоставляет инструменты, помогающие управлять проблемой, например, сообщая о конфликтах и ​​обеспечивая согласованные зависимости для иерархии проектов, и фактически обеспечивает абсолютный контроль над зависимости проекта.

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

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

Мдма
источник
5

Я считаю, что у Maven плохая репутация, потому что большинство недоброжелателей не заметили комбинации Maven + Hudson + Sonar . Если бы это было так, они бы спросили: «Как мне начать?»

Зак Томпсон
источник
+1 за упоминание Sonar.
Donal Fellows
1
Я видел это. По-прежнему нет причин использовать Maven. Хадсон и Сонар не нуждаются в maven.
rk2010
5

Некоторые из моих любимых раздражений с Maven:

  • Определение XML очень громоздкое и многословное. Они никогда не слышали об атрибутах?

  • В своей конфигурации по умолчанию он всегда просматривает сеть при каждой операции. Независимо от того, полезно ли это для чего-либо, крайне глупо требовать доступ в Интернет для «чистки».

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

  • Решение всего этого доступа к сети - отключить его, добавив -oопцию. Но не забудьте выключить его, если вы действительно хотите обновить зависимости!

  • Другое решение - установить собственный сервер «управления версиями» для зависимостей. Сюрприз: в большинстве проектов уже есть система контроля версий, только она работает без дополнительной настройки!

  • Сборки Maven невероятно медленные. Возня с сетевыми обновлениями смягчает это, но сборки Maven по-прежнему медленные. И ужасно многословно.

  • Плагин Maven (M2Eclipse) хуже всего интегрируется с Eclipse. Eclipse достаточно плавно интегрируется с ПО для контроля версий и с Ant. По сравнению с этим интеграция с Maven очень неудобна и уродлива. Я упоминал медленно?

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

оборота Карл Смотриц
источник
2
Я никогда не заставлял Maven извлекать последнюю версию из зависимости, если я не использовал зависимость SNAPSHOT или не добавил новую функцию, которая чего-то требовала. Если я прошу версию 1.2.3, и у меня будет 1.2.3 в моем локальном репозитории, я больше не получу 1.2.3.
Майк Корнелл
1
Да, вы контролируете свои прямые зависимости. Кто контролирует зависимости ваших зависимостей?
Carl Smotricz
Для вас первое, что касается атрибутов, которые, как предполагается, будут рассмотрены в будущем (я признаю, что уже
давно
@mezmo: Это было бы очень приятно. Спасибо за информацию!
Carl Smotricz
4

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

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

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

В наши дни Ant очень часто используется, и мне это нравится. Принимая это во внимание, я наткнулся на малоизвестного менеджера зависимостей под названием Apache Ivy . Ivy очень хорошо интегрируется в Ant и позволяет быстро и легко получить базовую настройку и работу для извлечения JAR. Еще одно преимущество Ivy в том, что он очень мощный, но при этом довольно прозрачный; вы можете легко переносить сборки с помощью таких механизмов, как scp или ssh; «цепное» извлечение зависимостей по файловым системам или удаленным репозиториям (совместимость с репозиториями Maven - одна из его популярных функций).

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

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

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

Вы можете найти следующие ресурсы, касающиеся Ivy:

Alex
источник
1
Ivy не конкурирует с Maven (возможно, с Maven Ant Tasks, но не с Maven).
Паскаль Тивент,
1
Ivy не конкурирует с Maven Ant Tasks, он конкурирует с управлением зависимостями Maven.
Дэмиен Би
@atc Это было правильно !! : «Я знаю, что скажет большинство людей - вам не обязательно соответствовать структуре. Действительно, это правда, но вы не узнаете этого, пока не пройдете начальную кривую обучения, и в этот момент вы потратили слишком много времени. пойти и выбросить все это ".
rk2010
4

Мне нравится Maven - он повышает продуктивность, и я очень рад, что больше не использую Ant (уф!)

Но если бы я мог что-то изменить, это было бы:

  1. Делать pom.xml файл менее подробным
  2. Упростите включение .jars не из репозитория.
облет
источник
1
Я думаю, что пользователям Maven было бы лучше, если бы IDE позволяли импортировать отсутствующие или сторонние jar-файлы в локальные репозитории. Насколько сложно было бы иметь диалоговое окно «выберите импорт щелчка по банке»?
sal
@sal Я предполагаю, что Maven не хочет продвигать практику, нарушающую переносимость.
Паскаль Тивент
1
Я считаю сильной стороной тот факт, что складывать банки из случайных мест сложно. Если вы находитесь в командной среде и вам нужно использовать нечетную банку, вы должны развернуть эту банку в репозитории maven вашей команды. Таким образом, остальная часть команды и ваши серверы CI будут выполнять одну и ту же сборку. Все используют одну и ту же сборку - это основа философии maven.
tunaranch
+1 за банку. Добавление собственных готовых jar-файлов в сборку (по любой причине) - излишняя боль.
Thorbjørn Ravn Andersen
@tunaranch лично мне нравится, что либо материал есть в Maven Central, либо он (банки и все такое) находится в том, что проверяется из системы контроля версий. По сути, я хочу иметь возможность перенести свой репозиторий git на USB-накопитель, проверить его, запустить «mvn clean install», пойти на обед и быть готовым.
Thorbjørn Ravn Andersen
4

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

Использовать Maven в простых проектах очень просто, для более крупных / сложных требуется больше знаний и более глубокое понимание философии Maven - возможно, на уровне компании должность гуру Maven, например сетевого администратора, будет на уровне компании. Главным источником сообщений о ненависти Maven часто является незнание .

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

Текущий успех Maven доказывает свою ценность. Конечно, никто не идеален, и у Maven есть свои недостатки и недостатки, но, на мой взгляд, Maven медленно меняет своих оппонентов.

cetnar
источник
@ Паскаль. В случае проблем с Maven есть stackoverflow и вы здесь :)
cetnar
3

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

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

Гленн
источник
«Я бы не сказал, что у него плохая репутация, поскольку у него смешанная репутация» - я бы сказал, что это, вероятно, более точно, только отрицательные мнения имеют тенденцию выделяться больше.
Дэн
Я согласен с тем, что перенос проекта на maven экспериментально увеличивает сложность по сравнению с размером проекта (больший проект для импорта = более сложный импорт). использование maven для запуска проекта - лучший подход к использованию maven. В противном случае это может не стоить усилий.
Luigimax
3

Для меня как плюсов, так и минусов в использовании maven vs ant для собственных проектов. Однако я думаю, что для проектов с открытым исходным кодом Maven оказал большое влияние, сделав создание многих проектов намного проще. Не так давно требовалось несколько часов для компиляции среднего проекта OSS Java (основанного на муравьях), необходимости установки тонны переменных, загрузки зависимых проектов и т.

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

Eelco
источник
3

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

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

Я был пользователем / жертвой maven более 5 лет, и должен сказать, что это сэкономит вам гораздо больше времени, если вы просто проверите свои зависимости в исходном репозитории и напишите красивые и простые задачи ant. Используя ant, вы ТОЧНО знаете, что делает ваша система сборки.

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

Недавно я попытался вернуть к жизни старый проект GWT / Maven / Eclipse, и спустя две недели из всего моего свободного времени я все еще не могу заставить его строить последовательно. Пришло время сократить мои потери и развиваться с помощью ant / eclipse, я думаю ...

Алекс Уорден
источник
3

Краткий ответ: мне было очень трудно поддерживать систему сборки Maven, и я хотел бы переключиться на Gradle как можно скорее.

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

Некоторые из уроков, которые я усвоил:

  • Большинство разработчиков не склонны тратить много времени на размышления о системах сборки; в результате сборка превращается в спагетти из хаков, но они ценят это, когда этот беспорядок очищается и рационализируется.
  • Имея дело со сложностью, я предпочел бы иметь прозрачную систему, которая раскрывает сложность (например, Ant), чем систему, которая пытается упростить сложные вещи, налагая жесткие ограничения, как Maven. Подумайте о Linux и Windows.
  • В функциональности Maven много дыр, которые требуют византийских обходных путей. Это приводит к тому, что файлы POM становятся непонятными и неподдерживаемыми.
  • Ant сверхгибкий и понятный, но файлы Ant тоже могут стать довольно большими, потому что они настолько низкоуровневые.
  • Для любого значительного проекта разработчики должны создать свою собственную структуру сборки / развертывания сверх того, что предоставляет инструмент; соответствие конструкции проекту во многом зависит от того, насколько легко ее поддерживать. Лучшие инструменты поддержат вас в создании структуры, а не будут бороться с вами.

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

бобтины
источник
3

Это сложнее, чем язык, на котором вы писали свой проект. Правильно его настроить сложнее, чем программировать.

Jpswain
источник
3

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

Если вы оптимизируете для коллег ( разработчиков с открытым исходным кодом ), подойдет ant / make / something. Если вы доставляете функциональные возможности другим пользователям ( пользователям ), подойдет только maven / gradle / etc.

Только maven позволяет вам выпустить небольшой пакет исходного кода + poms (без встроенных библиотек / двоичных jar-файлов зависимостей с загадочными именами и без информации о зависимостях) с хорошо документированным стандартным макетом проекта, который может быть загружен любой IDE кем-то, кто не усвоил идиосинкразические соглашения разработчиков о компоновке. И есть процедура установки с помощью одной кнопки (mvn install), которая собирает все, получая любые недостающие зависимости.

В результате пользователи могут легко найти путь в код, а помпы могут указать им на соответствующую документацию.

Помимо этого (необходимого) требования, я не люблю maven как никто другой.

оборота Bradjcox
источник