Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможным это стало благодаря одному из существенных изменений, реализованных в Maven 3. Я думаю, что такие попытки вполне оправданны — эта система оказалась очень удобной для пользователей из-за интеграции. Авторы этих изменений тесно сотрудничали с Eclipse, и отсюда возникло это решение. В нём архитектура была переделана, чтобы обеспечить лучшую поддержку в IDE. Я знаю, что у 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 8?
Кстати говоря, какое ваше мнение о Java 9, 10, 11?

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть