Почему у Знатока есть такой плохой представитель? [закрытый]

I wouldn't say it has a bad rep so much as it has a mixed rep. If your project follows the "convention over configuration" paradigm advocated by Maven then you can get a lot leverage out of it. If your project doesn't fit well into Maven's world view then it can become a burden.

To that end, if you have control over the project, then Maven may be the way to go. But if you don't and the layout is determined by someone not a fan of Maven, it may be more trouble than it's worth. The happiest Maven projects are probably the ones that started as Maven projects.

I think it has a bad reputation with people who have the most simple and the most complicated projects.

If you're building a single WAR from a single codebase it forces you to move your project structure around and manually list the two of three jars into the POM file.

If you're building one EAR from a set of nine EAR file prototypes with some combination of five WAR files, three EJBs and 17 other tools, dependency jars and configurations that require tweaking MANIFEST.MF and XML files in existing resources during final build; then Maven is likely too restricting. Such a project becomes a mess of complicated nested profiles, properties files and misuse of the Maven build goals and Classifier designation.

So if you're in the bottom 10% of the complexity curve, its overkill. At the top 10% of that curve, you're in a straitjacket.

Maven's growth is because it works well for the middle 80%

Maven is great. The reason for its reputation has got to do with the steep learning curve, in my opinion. (which I am finally close to getting over)

The documentation is a bit rough to wade through, simply because it feels like there's a lot of text and new things to comprehend before it starts making sense. I say time is all that's needed for Maven to become more widely praised.

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

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

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

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

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

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

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

(убедитесь, что вы получите ту же сборку через 6 месяцев)

отсутствие документации (документ достаточно хорош для основ, но не так много примеров, как работать с большими проектами)

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

(убедитесь, что вы получите ту же сборку через 6 месяцев)

отсутствие документации (документ достаточно хорош для основ, но не так много примеров, как работать с большими проектами)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошая часть состоит в том, что проблемы решаемы:

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

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

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

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

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

Я думаю, что разногласия возникают из-за того, что 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 ).

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

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

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

Я бы посоветовал не драться и не заставлять Maven делать то, что у него получается лучше всего, простые сборки или когда доступно стабильное моджо. В других случаях мы выпадаем из программы и делаем что-то либо с помощью Ant-задач ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) или внешних программ. Мой личный фаворит - плагин Groovy ( http://groovy.codehaus.org/GMaven ).

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

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

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

Я бы посоветовал не драться и не заставлять Maven делать то, что у него получается лучше всего, простые сборки или когда доступно стабильное моджо. В других случаях мы выпадаем из программы и делаем что-то либо с помощью Ant-задач ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) или внешних программ. Мой личный фаворит - плагин Groovy ( http://groovy.codehaus.org/GMaven ).

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

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

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

или когда доступен стабильный моджо. В других случаях мы выпадаем из программы и делаем что-то либо с помощью Ant-задач ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) или внешних программ. Мой личный фаворит - плагин Groovy ( http://groovy.codehaus.org/GMaven ).

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

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

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

или когда доступен стабильный моджо. В других случаях мы выпадаем из программы и делаем что-то либо с помощью Ant-задач ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) или внешних программ. Мой личный фаворит - плагин Groovy ( http://groovy.codehaus.org/GMaven ).

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

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

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

Мой личный фаворит - плагин Groovy ( http://groovy.codehaus.org/GMaven ).

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

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

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

Мой личный фаворит - плагин Groovy ( http://groovy.codehaus.org/GMaven ).

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

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

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

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

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

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

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

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

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

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

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 с задачами в каталог lib вашего муравья.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые из моих домашних животных с Maven:

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

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

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

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

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

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

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

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

Примечание: Проблема не ограничивается Linux, она существует и в Windows (и, предположительно, в Mac). Прочтите другой (не переполнение стека) источник всех знаний: Википедия о возврате каретки .

Если требуется выполнить повторную привязку C-m , обязательно выполните привязку < return > , иначе вы рискуете больше не быть использовать клавишу Enter/Return. Кроме того, в терминале Emacs не может различать их ( C-m и < return > ).

В простом Emacs клавиша Enter/Return привязана к < return > , который (по умолчанию) преобразован в RET (то же самое, что и C-m ). Если отскочить только C-m , вы также повлияете на клавишу Enter/Return.

Попробуйте C-h k < return > , и вы увидите

RET (в переводе с < return >)

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

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

(defun my-return ()
  (interactive)
  (message "return"))
(defun my-ret ()
  (interactive)
  (message "RET"))
(defun my-c-m ()
  (interactive)
  (message "C-m"))
(global-set-key (kbd "<return>") 'my-return)
(global-set-key (kbd "C-m") 'my-c-m)
(global-set-key (kbd "RET") 'my-ret)

Поместите его в буфер * scratch * и нажмите C-j после каждой строки (чтобы оценить sexp). Затем нажмите клавиши Enter/Return и C-m .

-121--2426914-

Основным источником проблемы является то, что Enter и Ctrl-M сопоставляются с одним и тем же кодом ASCII (13). Вы сможете сопоставить их только на системе, которая может их отличить.

-121--2426918-

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

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

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

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

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

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

1. когда причиной являются реальные проблемы (например, подробные POM, отсутствие документации),
2. некоторая часть представляет собой дезинформацию (например, «вам необходимо подключение к Интернету для создания» - неправда - делаешь » t, этого можно избежать),
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, переопределяющее зависимость), а не неявными, как в случае с управляемыми вручную jar-файлами в системе контроля версий, где jar-файлы просто присутствуют без каких-либо изменений. поддерживать погоду они правильная зависимость или нет.

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

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

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

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

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

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

Я бы выделил Maven 1 и 2: у первого (заслуженно) плохая репутация; последнее является улучшением и растущим «стандартом».

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

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

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

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

Наша основная проблема возникла из-за того, что различные компоненты в репозитории maven2 по умолчанию зависят от разных версий одной и той же библиотеки (т. Е. Компонент 1 и компонент 2 требуют фреймворка журналирования, но компонент 1 требует v1, а компонент 2 требует v2).

Чтобы Чтобы решить эту проблему, у нас просто есть собственный локальный репозиторий, содержащий все необходимые библиотеки.