Как стать автором
Обновить

«У нас есть идеи для Maven 4 и даже Maven 5» — интервью с Robert Scholte, ключевым участником проекта Maven

Время на прочтение 11 мин
Количество просмотров 7K
Всего голосов 32: ↑29 и ↓3 +26
Комментарии 11

Комментарии 11

Для тех кому надоела многословность XML, а Polyglot использовать нет возможности или желания, есть плагин для IDEA, который эту многословность скрывает.
Мне помогает этот опыт, поскольку, например, в случае с module descriptor, появившемся в Java 9, мне использовать его в плагинах к Maven.

Мне кажется тут небольшая неточность в переводе.
Надеюсь не ошибся.
Не ошибся, спасибо.
В будущем предлагаю все косяки писать в личку, иначе комментарии превратятся в ад из корректировок. К сожалению, Хабр пока не умеет принимать коммиты :)
Мы решили, что разделим pom-файл на несколько частей, и начнём с Build POM. А тот, который будет выгружаться, будет называться Consumer POM

НАКОНЕЦ-ТО!!! Наконец-то до них дошло, что build script и artifact metadata это разные артифакты и смешивать их нельзя!!!

До кого это «до них»? Вообще-то у мавена всегда было так, что pom.xml это метаданные. А «скрипты» — это плагины, которые как раз хранятся отдельно.

Сделать иначе можно — но это уже потребует определенных усилий. И те кто так делает — либо ССЗБ, либо решают явно нестандартные задачи (более того, вот в моей практике для стандартных задач скрипты вообще требовались в исключительно редких случаях — практически никогда).

И да, во всех тех системах сборки, которые основаны изначально на скриптовом языке, т.е. gradle, sbt, leiningen — там с метаданными бывает намного хуже.

откуда качать зависимости — это часть билда, не metadata. Какие плагины в каком порядке запускать — это часть билда, не metadata.


Metadata это то, что выдает в pom, например gradle – id, url, cms, authors, description, зависимости. Всё.


Как строить (не важно, в коде это описано, или в XML) – это часть скрипта.


И в Gradle с метаднными, конечно, намного лучше. Ты просто генеришь их в том формате, в котором захочешь — pom.xml, ivy.xml, и публицируешь сместе с артифактами. Полное разделение от скрипта, как и должно быть.

>откуда качать зависимости — это часть билда, не metadata.
А это не в pom лежит. Точнее, запретить это туда сунуть вряд ли можно, но что это конкретно не рекомендуется — вполне четко сформулированное заявление.

>Какие плагины в каком порядке запускать — это часть билда, не metadata.
Плагины, в порядке? Я с 2005 года на мавене, и никогда не указывал порядок. Так что это как минимум перебор. Вообще, в реальных проектах у меня редко бывает больше двух плагинов.

>И в Gradle с метаднными, конечно, намного лучше. Ты просто генеришь их в том формате, в котором захочешь — pom.xml, ivy.xml,
Это ваше право так считать. Вполне допускаю, что такое поведение приемлемо, но для меня оно не годится категорически. Генеришь — это значит, что ты должен фактически собрать проект (а иначе откуда гарантия, что метаданные актуальны, и вообще там есть?).

А значит, ты должен знать и иметь слишком много для того, чтобы просто узнать координаты проекта (группа, артефакт, версия и т.п.) и список зависимостей. Скажем, я вполне себе обрабатываю кучу проектов одним скриптом, доставая при этом что-то из Git, из Nexus (и любого другог репозитория), из Jenkins, из Jira — и все это одновременно. И эта обработка реализуется на чем угодно, начиная от Python и кончая javascript. При этом pom я естественно нормально обрабатываю, потому что xml знает любой браузерный javascript. Я даже jar смогу распаковать в браузере, если чуть напрягусь. Но о наличии gradle в браузере и речи быть не может.
А это не в pom лежит. Точнее, запретить это туда сунуть вряд ли можно, но что это конкретно не рекомендуется — вполне четко сформулированное заявление.

Конечно лежит. Тэг <repositories> никто не запрещал, и наша статистика по стиранию этого тэга автоматически в Артифактори удручает.


Плагины, в порядке? Я с 2005 года на мавене, и никогда не указывал порядок. Так что это как минимум перебор. Вообще, в реальных проектах у меня редко бывает больше двух плагинов.

Это, мягко говоря, лукавство. В тэге <phase> указывается, в какой фазе плагин запускать. Более того, само перечисление плагинов это уже детали сборки, которым нечего делать в документе метадаты артифакта.


Генеришь — это значит, что ты должен фактически собрать проект.

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


иначе откуда гарантия, что метаданные актуальны, и вообще там есть?

Ну, гарантия, например, из логики генерации этой метадаты из скрипта. Если зависимости достаточны для того, чтобы сборка в Грейдле прошла, и эти зависимости попадают в сгенерированный pom.xml, очевидно, эта метадата верна. Если это не так, Грейдлу надо чинить баги.


На счет обработки, я не очень понял, к чему этот параграф вообще. Тебе для чего-то нужны все подробности о процессе сборки? Прекрасно, они есть в source control, рядом с сорцами (которые тоже нужны для сборки). Просто эти подробности не являются метаданными артифакта, и путать эти 2 понятия, как это исторически делал Мавен — нехорошо. Рад, что наконец до них дошло.

Хм.


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


  • я за 13 лет никогда не видел реальных проблем, вызванных неверным указанием phase. То есть, серьезность этой проблемы близка к нулю. Кроме того, если вы перепутаете порядок выполнения чего-либо в коде, который будет отдельным билд скриптом — то результат будет тот же самый. Так что разделение тут на "якобы метадату" и "якобы скрипт" мало что не изменит. Ну или это надо продемонстрировать.
  • если у вас в pom указаны репозитории, возможно для Артифактори это и проблема, но опять же — не для меня.

А точнее так — указание репозиториев в pom это реальная проблема, только она лежит не там, где описано. Это означает, как правило, что какой-то зависимости нет в central. Вы можете что угодно сделать с этим pom, и куда угодно вынести указание на репозитории, но проект от этого собираться не станет. То есть, проблема именно в том, что зависимости нет в central, и лечить ее надо в первую очередь там. И уж точно она не решается выносом указания на репозитории куда-то в другой скрипт, потому что нужного репозитория тупо может не быть вообще.


Эта фраза как раз показатель, что разницу между скриптом и метадатой я плохо объяснил. Из метадаты ничего нельзя "собрать",

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


На счет обработки, я не очень понял, к чему этот параграф вообще. Тебе для чего-то нужны все подробности о процессе сборки?

Нет. Зачем мне скажем плагины? Мне нужны а) координаты проекта и б) зависимости (изредка). Это именно метадата. Хотя да, если я хочу сами зависимости, мне нужны репозитории так или иначе, и я их беру из settings.xml. Оба файла, что характерно, простой xml.


И тот факт, что в pom еще лежит много чего, что называется "скриптом", мне совершено не мешает обрабатывать этот pom любым инструментом. Все что мне надо — это корень минус тэг . Это и есть метадата, это почти никогда не ломается, и не является кодом. Хотя если честно — то да, стоит подставить в качестве значения версии ${spring.version} — и наша метадата внезапно стала вычисляемой.

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


Ну т.е. скажем, построить граф зависимостей между проектами в рамках одного условного репозитория. Кто от кого зависит, какие где версии, что нужно релизить, если вот этот и вот этот выпустят новые major/minor версии. У этих задач нет хорошего решения, или я его не знаю. И мне бы maven новой версии мог помочь тут очень просто — если бы весь формат pom (один или несколько) был бы условно говоря, как сегодня doap. При этом будь он скажем RDF, его можно было бы бить на части легко и непринужденно — главное репозиторий завести для частей.

У нас есть идеи для Maven 4 и даже Maven 5

Хм, кто бы еще воплотил в жизнь идеи для Maven 3. Проект полиглот, например, посмешище полное.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий