company_banner

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

    Признайтесь, все мы долгими вечерами и ночами чинили билды в Maven, и в эти минуты очень хотелось сказать пару ласковых создателям этой чудной технологии. Иногда мечты сбываются! Нам с Женей (phillennium) попался чуть ли не самый главный разработчик Maven — Robert Scholte. И вот о чём мы его спросили…



    Читать дальше →


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


    Если вы говорите о 6-месячном релизном цикле, то для Maven это немного быстровато. Наша команда достаточно маленькая, у нас примерно 5-10 активных участников, и они все добровольцы, никакая компания разработкой Maven не занимается. А значит, все должны работать над проектом в свободное время. Изменения в Java создают много работы. Каждый раз, когда выходит новая версия, нам нужно обеспечить её поддержку, а это значит, что у нас нет времени на Maven, плагины к нему или что-либо ещё. Для меня было бы лучше, если бы цикл был длиной в год или полтора.




    Есть ли похожее ощущение у других людей, разрабатывающих проекты для экосистемы Java, которым также нужно обеспечивать поддержку новейших версий?



    Если судить по твиттеру, то да, большинство согласны, что 6 месяцев — это слишком быстро.




    Могли бы вы рассказать историю Maven? Если я правильно помню, он был создан давным-давно, чтобы сделать сборку Apache Turbine менее страшной и болезненной. Я, кстати говоря, пользовался Apache Turbine. Помните ли вы это время?


    История Maven началась очень давно. Я присоединился к проекту примерно 8 лет тому назад, то есть во время версии 3.0.3 или 3.0.4. И на этот момент Maven существовал уже достаточно долго. Насколько я знаю, он входил в проект Turbine. Из части этого проекта был сделан отдельный инструмент, который и стал Maven. Я, как и, наверное, все, пользовался тогда Ant. Мне не нравилось, что каждый раз, когда я начинал работу над новым проектом, мне нужно было копировать все эти Ant-файлы. Я знал, что должно быть решение лучше, я стал его искать в интернете и нашёл Maven. Правда, прежде, чем я понял основную идею Maven, прошло достаточно много времени. Однако когда его понимаешь, становится удобно. Все проблемы, которые у меня были с Ant, исчезли. Ant по-прежнему является отличным средством, но если вы работаете над проектом, объединяющим множество исходников, я всячески рекомендую Maven или аналогичный инструмент.




    Maven — это только про Java. Я пробовал использовать его для С++, но это было не очень приятно. Не настанет ли время, когда Java больше не будет, и что мы тогда будем делать?


    Из существующих популярных объектно-ориентированных языков Java, кажется, одна из самых старых, ей уже больше 20 лет. Не смотрел последнюю статистику, но уверен, что Java по-прежнему очень широко распространена. Думаю, она будет существовать еще довольно долго. По крайней мере, я на это надеюсь — это значит, что я не останусь без работы.




    А Maven тоже будет жить долго?


    А вот это сложный вопрос. До сегодняшнего дня в 65-80% проектов на Java используется Maven. Даже для продукта, которому больше 15 лет, это очень много. Наверное, в Maven ещё многое можно улучшить. У нас есть идеи для Maven 4 и даже Maven 5. Но на их реализацию потребуется много времени. Думаю, общий замысел Maven не устареет, но его вполне могут обогнать другие системы сборки. Потому что они извлекают опыт как из тех ошибок, которые мы сделали в Maven, так и из тех решений, которые мы приняли правильно, и на основании этого опыта могут начать с чистого листа. Одно из преимуществ Maven — обратная совместимость. Даже проект, написанный 10 или 15 лет назад, можно собрать при помощи последней версии Maven. Но из-за этого у нас много старого кода в Maven Core. Его следует заменить, но сделать это не так-то просто.



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


    Да, это возможно.




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


    Gradle — очень сильный конкурент, и он существует уже довольно давно. Я считаю, что наличие конкуренции — это хорошо, поскольку держит нас в форме и даёт нам увидеть некоторые альтернативные решения. У них просто другой подход к тому, как собирать проекты, в этом нет ничего плохого. Каждому следует выбрать то, что лучше подходит своему проекту. Возможно, мне здесь также следует упомянуть pro. Это инструмент, написанный Реми Фораксом (Remi Forax) из команды ASM (парсера байткода). Он, как и я, входил в экспертную группу проекта Jigsaw. Он хотел написать такой инструмент для сборки, который лучше всего отражал бы идеи Java. При создании pro он заимствовал лучшие аспекты Maven. Наблюдать за этим было интересно. Это была демка, созданная чтобы показать, что в сборщике можно использовать модули Java 9 и связанные с ними преимущества.




    Вы сказали, что участвовали в проекте Jigsaw — и сказали это в прошедшем времени. Он прекратил своё существование? Есть ли у него ещё возможность развиваться?


    Этот JSR закрыт. Правда, остались некоторые неразрешённые проблемы, но ими теперь занимается команда поддержки.




    Что вызвало больше всего трудностей при разработке Maven? Какие проблемы были наиболее серьёзными? Не в плане Java 9, а вообще, исходя из всего опыта разработки. Сможете выбрать, скажем, две наиболее важных проблемы?


    Вопрос непростой, но давайте попробуем. Часть, в которой происходит разрешение зависимостей, чрезвычайно сложна. Мы по-прежнему стараемся её улучшить. Возможно, вы заметили, что версии Maven 3.4 не было, после версии 3.3.9 была сразу 3.5.0. Основная причина этого в том, что произошли существенные изменения в разрешении зависимостей. Они были помечены как багфиксы, но мы обратили внимание, что значительное количество проектов внезапно оказались сломаны — они зависели от этих странных изменений. Это было недопустимо. Поэтому мы сделали то, что ни при каких других обстоятельствах не предприняли бы — hard-reset git-репозитория, и в Maven 3.5.0 стали отбирать только внешние улучшения. Ну, и, конечно, мы сделали консоль разноцветной — это понравилось всем.




    Хорошо, теперь очередь второй трудности!


    Нам непросто было найти связь с сообществом Maven и научить их правильно пользоваться инструментом.




    Так все знают, как пользоваться Maven: скопировать несколько портянок XML из комментариев на Stack Overflow, и всё заработает. Разве нет?


    Ну-ну. Нет. Я уверен, что чаще всего вам посоветуют сделать clean install, и это неверно. Так, наверное, следовало делать в Maven 2. Теперь нужно выполнять mvn verify. Потому что при выполнении clean у вас удаляется вообще всё, весь результат работы. А если у вас копируются файлы — это операции ввода/вывода, они выполняются медленно. В общем, многие вещи будут выполняться много лишних раз. Большинство плагинов знают, когда им нужно выполнять свою задачу. Как правило, в clean потребности нет. Что касается install, то эта команда только копирует ваши JAR-файлы в локальный репозиторий. Это, опять-таки, ненужная операция ввода/вывода. Больше того, ваш локальный репозиторий может стать грязным — то есть он может выглядеть иначе, чем локальный репозиторий вашего коллеги. Иногда это может привести к интересным результатам. Так что следует просто выполнять mvn verify, этого достаточно.




    Кстати говоря, я сейчас открыл maven.apache.org, и там написано: «Apache Maven is a software project management and comprehension tool». Но многие считают, что Maven — это просто очередной инструмент для сборки. В чём разница между инструментом для сборки и средством по управлению проектом?


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




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


    Думаю, что нет. На наш взгляд, конфигурацию плагинов следует делать как можно более простой. Если существуют разумные значения по умолчанию, их следует указывать. Это упростит жизнь конечному пользователю. Впервые за многие годы мы недавно изменили вариант по умолчанию для версий source и target — раньше он был 1.5, теперь — 1.6. Мы хотели, чтобы присутствовал вариант по умолчанию, поскольку без него используется та версия, что в JDK. В этом случае, если я использую Java 10, а кто-то другой — Java 12, у нас будут разные результаты. Всегда следует указывать source и target. Но если вы начали пользоваться Java 9, вы уже не сможете создать Hello World с простым pom-файлом и одним классом, поскольку Java 9 требует по меньшей мере Java 6 для значения source и target. Поэтому мы решили сделать версией по умолчанию 1.6 и добавили предупреждение о том, что если вы ещё не указали версию, это следует сделать — люди должны знать, что нужно выставлять либо версию source и target, либо значение release, если вы работаете с Java 9. Или и то, и другое одновременно.




    Какие трудности вы видите для Maven в будущем? Вы говорили, что стараетесь не менять Maven слишком часто. И всё же, что нас ожидает в будущем?


    Одно из наиболее существенных изменений из тех, которые мы хотим внести, касается pom-файла. Мы обнаружили, что в некоторых секциях — в особенности в build — неплохо было бы добавить некоторые дополнительные элементы. Но пока что мы сделать этого не можем. Выгружается тот же pom-файл, который вы используете на своей системе. Если к нему добавить другие элементы, они нарушат XSD, и другие инструменты не смогут им пользоваться.




    Но ведь можно поменять XSD в заголовке?


    Да. Но я не думаю, что каждый инструмент проверяет XSD. Они просто считают, что имеют дело с версией 4.0.0. Так что внести изменения будет очень сложно. Мы решили, что разделим pom-файл на несколько частей, и начнём с Build POM. А тот, который будет выгружаться, будет называться Consumer POM. Он будет генерироваться на основе Build POM и никаких дополнительных действий предпринимать не нужно. И он будет полностью совместим с версией Maven POM 4.0.0. Разделив POM на две части, мы сможем, наконец, существенно его улучшить и сделать Maven более простым в использовании. Это изменение в ядре Maven, и мы работаем над ним уже больше года, включая реализацию в IDE. Это непросто.




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


    Я думаю, что такие попытки вполне оправданны — эта система оказалась очень удобной для пользователей из-за интеграции. Возможным это стало благодаря одному из существенных изменений, реализованных в Maven 3. В нём архитектура была переделана, чтобы обеспечить лучшую поддержку в IDE. Авторы этих изменений тесно сотрудничали с Eclipse, и отсюда возникло это решение. Я думаю, что это допустимо. Я знаю, что у NetBeans и InelliJ подход совсем другой, они просто вызывают Maven из командной строки без какой-либо интеграции.




    Другая важная тема — скорость Maven. Можем ли мы её как-либо увеличить? Разрешение зависимостей и операции ввода/вывода происходят очень медленно. Даже сегодня на SSD.


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




    Вы сказали, что работаете над Maven в своё свободное время, правильно? Помогает ли тот факт, что вы один из создателей Maven, в вашей нынешней работе? Или это только хобби?


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




    Работаете ли вы над другими опенсорсными проектами, помимо Maven?


    Я участвую в двух других проектах. Один называется MojoHaus, в нём была разработана значительная часть плагинов для Maven. Правда, сейчас я мало что делаю в этом проекте, но по-прежнему иногда туда заглядываю и правлю разные мелочи. Другой проект называется QDox. Он осуществляет синтаксический разбор исходного кода. Он тоже связан с Maven, так как используется в некоторых плагинах к нему. Мне помогает этот опыт, поскольку, например, в случае с module descriptor, появившемся в Java 9, опыт позволил применить дескриптор в плагинах к Maven.




    Кстати говоря, какое ваше мнение о Java 9, 10, 11? Стоит ли ими пользоваться или лучше остановиться на Java 8?


    Cледует переходить на более новые версии. Даже если вы не используете все возможности, следует перейти на Java 10, или подождать несколько недель и перейти на Java 11. Просто используйте classpath. Java стала значительно быстрее благодаря модульности, но classpath просто работает. Я знаю, что многие по-прежнему думают, что нужно добавлять module descriptor или использовать систему модулей, но это необязательно. Просто используйте classpath.




    Кстати, знакомы ли вы с проектом GraalVM? Как насчет использовать его для сборки Maven?


    На прошлой неделе я посещал JavaZone и обсуждал это с Крисом и Олегом. Я думаю, что нам нужно будет провести некоторое время с этим, посмотреть, возможно ли действительно улучшить производительность Maven при помощи GraalVM. Это может быть интересно.




    Вы — создатель Maven, проекта, который очень важен для разработчиков на Java. Какие ваши ощущения по этому поводу?


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



    Многие разработчики яро ненавидят XML. Я к их числу не принадлежу, но когда речь идёт о системах сборки, эта тема вечно всплывает в связи с pom.xml в Maven. Поэтому хочется узнать: какое ваше мнение об XML?


    В XML хорошо то, что он всем понятен, его просто парсить и для него можно обеспечить очень хорошую поддержку в IDE. Я вполне нормально отношусь к XML, и, насколько я знаю, среди пользователей Maven не больше 5% ненавидят XML — зато они кричат об этом во всё горло! А остальных 95% вы просто никогда не слышите. Тем не менее, для этих 5% есть решение — тут я опять хочу упомянуть Takari. Там есть проект polyglot, который позволяет выбрать другой синтаксис. Так что если вы хотите использовать Yaml и pom.yml — это вполне возможно. К проекту просто нужно добавить расширения, и можно будет переключиться на другой язык.




    И ещё о настроениях разработчиков: вспоминается тред в рассылке Maven, где автору инструмента SDKMAN! на предложение распространять через него Maven сообщество ответило фразами вроде «всё, что я вижу — проект с дурацким названием» и «ты мог бы и получше продавать свою идею». Тогда возникли дискуссии: одни считали, что сообщество отреагировало слишком агрессивно, другие — что исходное предложение «проделывайте дополнительные действия в связи с моим инструментом» было необоснованным. Так или иначе, многие были недовольны ситуацией, и в связи с этим вопрос: считаете ли вы, что конкретно у Maven или вообще у опенсорсного сообщества есть проблемы с коммуникацией?


    Общение может быть весьма и весьма непростым, это точно. В особенности когда оно происходит только через текст и вы не видите собеседника перед собой — в этой ситуации становится сложно объяснить, что ты хочешь сказать. Я думаю, перед каждым опенсорсным проектом встаёт эта проблема корректного общения с людьми. Я вполне понимаю, почему участники проекта иногда приходят в раздражение — они слышат одни и те же вопросы снова и снова. Пример такого вопроса, который я уже упоминал — «почему нельзя использовать mvn clean install»? Я перестал это объяснять, потому что иначе я сам превратился бы в грубияна, а мне этого не хочется. Так что я объясняю такие вещи другими способами. Итак, с одной стороны, коммуницировать может быть очень непросто. А с другой, хотя Maven и бывает негибким, это является частью его успеха. Когда люди приходят с предложениями, которые несовместимы с нашей концепцией Maven, мы просто говорим: извините, но это нам не подходит по таким-то причинам. Я вполне понимаю, что это может вызвать разочарование. Но в целом такой подход только к лучшему.




    Могли бы вы под конец сказать несколько слов нашим читателям, подсказать, как им прийти к светлому будущему?


    Как я уже говорил, над Maven работает небольшая команда, это опенсорсный проект, в котором все могут участвовать. Это не так уж и сложно. Мы создали новую метку, которая называется «up for grabs». Это проблемы, которые должно быть не слишком сложно пофиксить. Таким образом вполне можно познакомиться с тем, как работает Maven. Если вы хотите присоединиться к нашей команде, то на примере ваших фиксов нам будет видно качество вашего кода — если вы хотите быть замеченными нами, то я рекомендую это попробовать. Мне очень хотелось бы, чтобы наша команда выросла в будущем.




    Спасибо за ответы. Встретимся на Joker 2018!


    Минутка рекламы. 19-20 октября состоится конференция Joker 2018, на которой Роберт выступит с докладом «Apache Maven supports ALL Java». В целом, на Joker будет ещё множество интересных и заслуживающих пристального внимания докладов. Приобрести билеты можно на официальном сайте конференции.
    JUG Ru Group
    Конференции для программистов и сочувствующих. 18+

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

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

        Мне кажется тут небольшая неточность в переводе.
        Надеюсь не ошибся.
          –2
          Не ошибся, спасибо.
          В будущем предлагаю все косяки писать в личку, иначе комментарии превратятся в ад из корректировок. К сожалению, Хабр пока не умеет принимать коммиты :)
            +2

            Пока? :) Учёный изнасиловал журналиста! На хабре скоро будут коммиты!!!

          +4
          Мы решили, что разделим pom-файл на несколько частей, и начнём с Build POM. А тот, который будет выгружаться, будет называться Consumer POM

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

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

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

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

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


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


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


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

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

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

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

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

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


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

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


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

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


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

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


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

                    0

                    Хм.


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


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

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

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

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

            Самое читаемое