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

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

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

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

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

Я заглянул в 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 невозможно разделить на просто усвоенные звуковые фрагменты. Революционные идеи часто трудно передать словами.

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

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

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

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

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

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

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

Мой практический опыт работы с двумя крупными проектами показывает, что мы потратили 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, насколько это возможно. Кроме того, защитники, как правило, относятся к тому типу людей, которые празднуют свой день рождения, когда их возраст - простое число. Не стесняйтесь голосовать за меня :-)

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

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

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

Плюсы:

• Управление зависимостями. Вот уже несколько лет я и мои коллеги не загружаем и не управляем зависимостями вручную. Это огромная экономия времени.
• 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 уже несколько лет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Таким образом, ваши релизные сборки всегда будут точным описанием всех зависимостей.

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

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

Год спустя я хотел обновить это: у меня больше нет такого мнения о сообществе 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. Не знаю, разделяет ли кто-нибудь это мнение.

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

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

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

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

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

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

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

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

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

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

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

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

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

С уважением

v.

Мне нравится 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, переопределяющее зависимость), а не неявными, как в случае с управляемыми вручную банками в системе контроля версий, где банки просто присутствуют, и нечего поддерживать погоду они правильная зависимость или нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сравнение Apache Ivy и Maven 2
• Часто задаваемые вопросы об Apache Ivy
• Список возможностей Apache Ivy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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