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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

  • С самого начала он навязывает вам жесткую структуру.
  • Он основан на XML, поэтому его трудно читать как ANT.
  • Отчет об ошибках неясен и оставляет вас в затруднительном положении, когда что-то идет не так.
  • Документация плохая.
  • Это упрощает и упрощает работу.
  • Требуется слишком много времени, чтобы поддерживать среду сборки Maven, которая побеждает в том, что у вас есть всепользовательская система сборки.
  • Требуется много времени, чтобы понять, что вы обнаружили ошибку в maven и не настроили что-то неправильно. И ошибки существуют, и в удивительных местах.
  • Это promises много, но предает вас, как красивый и соблазнительный, но эмоционально холодный и манипулирующий любовник.

Ответ 3

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

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

Недостатки для меня в основном:

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

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

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

Ответ 8

Плюсы:

  • Управление зависимостями. Уже несколько лет мои коллеги и я не загружаем и не управляем зависимостями вручную. Это огромная экономия времени.
  • 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 plugun (http://groovy.codehaus.org/GMaven).

Конкурс:

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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>

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

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

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

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

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

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

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

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

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

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

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

Воспроизводимая проблема сборки разбивается на две проблемы, диапазоны версий и автоматические обновления плагина maven. Для плагинов вверх, хорошо, если вы не убедитесь, что когда вы перестраиваете проект через год, вы используете точно такую ​​же JDK и точно такую ​​же версию ant, ну, это же проблема с другим именем. Для диапазонов версий я рекомендую работать с плагином, который будет создавать временную память с заблокированными версиями для всех прямых и транзитивных зависимостей и сделать ее частью жизненного цикла релиза maven. Таким образом, ваши версии build poms всегда являются точными описаниями всех зависимостей.

Ответ 12

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

Более того, когда все не работает, вы абсолютно потеряны. Документация сосет, сообщество невежественно.

Ответ 13

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

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

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

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

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

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

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

Ответ 14

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

Ответ 15

Слишком много волшебства.

Ответ 16

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

Ответ 17

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

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

Контрастируйте это с помощью сборки ant, которая - хотя многословная и утомительная IMO - работает, поскольку все банки проверены локально.

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

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

Ответ 18

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

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

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

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

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

рассматривает

v.

Ответ 19

Некоторые из моих любимых мобов с Maven:

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

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

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

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

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

  • Конструкции Maven невероятно медленны. Слияние с сетевыми обновлениями облегчает это, но сборки Maven все еще медленны. И ужасно многословный.

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

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

Ответ 20

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

  • где причины являются реальными проблемами (например, подробные POM, отсутствие документации),
  • некоторые из них являются дезинформацией (например, "вы должны иметь подключение к Интернету для сборки" - не верно - doin't, этого можно избежать),
  • некоторые из них выпущены на maven, но действительно кто-то другой виновен ( "не стреляйте в посланника" ).

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

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

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

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

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

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

Ответ 21

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

Ответ 22

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

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

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

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

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

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

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

Возможно, вам понадобятся следующие ресурсы, относящиеся к плющам:

Ответ 23

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

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

  • Сделать pom.xml файл менее подробным
  • Упростите включение .jars не из репозитория.

Ответ 24

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

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

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

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

Ответ 25

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

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

Ответ 26

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

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

Ответ 27

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

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

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

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

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

Ответ 28

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

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

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

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

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

Ответ 29

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

Ответ 30

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

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

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

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

Помимо этого (непременного) требования, мне не нравится maven столько, сколько кому угодно.