Признайтесь, все мы долгими вечерами и ночами чинили билды в 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 будет ещё множество интересных и заслуживающих пристального внимания докладов. Приобрести билеты можно на официальном сайте конференции.
Автор: Олег Чирухин
