С небольшой разницей во времени произошли два события: у Gradle вышла версия 3.1, а у разработчика Gradle-плагина Spring Boot вызвали вспышку гнева проблемы с совместимостью, появившиеся с 3.0.
Главным нововведением 3.1 стали Сomposite Builds, состоящие из нескольких билдов («Это позволяет объединять билды, которые обычно разрабатывают независимо — например, при проверке багфикса в библиотеке, которую использует ваше приложение»). Помимо этого, была доработана функция Incremental Build, ускорилось разрешение зависимостей при определённых условиях (особенно в Android), улучшилась поддержка Play Framework (появилась начальная поддержка версий 2.5.x) и билд-скриптов на Kotlin.
А история с проблемами совместимости в следующем. Энди Вилкинсон из Pivotal столкнулся с тем, что изменения в API Gradle 3.0 сделали несовместимым с новой версией плагин Spring Boot для Gradle, наследующий org.gradle.api.DefaultTask. Поддерживать две разных версии плагина для разных версий Gradle он считает плохим решением, и возник вопрос «как перестать зависеть от того, что вызвало изменения, чтобы один плагин по-прежнему подходил для всего».
Однако избавление от зависимости выглядело настолько трудоёмкой задачей, что выпуск Gradle 3.0 сильно осложнил Вилкинсону жизнь. Это разозлило его настолько, что он не только написал на форуме Gradle пост с вопросом «как разработчикам плагинов быть в такой ситуации?», но и сослался на него в твиттере со словами «очередное о том бардаке, что называется внутренностями Gradle, хотя на деле торчит наружу».
С официального аккаунта Gradle ему пришёл реплай примерно такого содержания: «Да, хреново Извиняемся, что доставили столько боли. Опубликовали на форуме ответ».
В ответе на форуме Эрик Уэнделин (Gradle) извинился за «протёкшую абстракцию», после чего как озвучил конкретный план действий на текущий момент, так и пообещал в долгосрочной перспективе изменить ситуацию с публичными API в целом, активно обсуждая её с сообществом («это будет непросто, но мы не можем продолжать подход “наспех чинить каждый конкретный случай”»). Одной из причин возникновения проблем он считает смену версии Groovy, однако уточняет, что винить язык неправильно: «Мы должны были понимать, что переход на новую версии Groovy может сломать нам совместимость».
Прочитав ответ Уэнделина, Уилкинсон написал, что зря погорячился и высказался неконструктивно, а также что «обсуждать проблему с сообществом» звучит отлично, и он будет рад в этом поучаствовать. Ну будущее он предложил Gradle использовать в своих собственных плагинах исключительно публично доступные API: «понимаю, что это проще сказать, чем сделать, но если бы все собственные плагины Gradle были написаны лишь с публичными API, разработчикам других плагинов стало бы гораздо проще предоставлять схожую функциональность». Уэнделин согласился с тем, что это находится в корне проблемы, хотя это и «будет очень сложно распутать».
В общем, отработка негативного фидбэка у Gradle впечатляющая — до решения проблемы ещё далеко, а человек уже превратился из хейтера в лояльного пользователя.
Главным нововведением 3.1 стали Сomposite Builds, состоящие из нескольких билдов («Это позволяет объединять билды, которые обычно разрабатывают независимо — например, при проверке багфикса в библиотеке, которую использует ваше приложение»). Помимо этого, была доработана функция Incremental Build, ускорилось разрешение зависимостей при определённых условиях (особенно в Android), улучшилась поддержка Play Framework (появилась начальная поддержка версий 2.5.x) и билд-скриптов на Kotlin.
А история с проблемами совместимости в следующем. Энди Вилкинсон из Pivotal столкнулся с тем, что изменения в API Gradle 3.0 сделали несовместимым с новой версией плагин Spring Boot для Gradle, наследующий org.gradle.api.DefaultTask. Поддерживать две разных версии плагина для разных версий Gradle он считает плохим решением, и возник вопрос «как перестать зависеть от того, что вызвало изменения, чтобы один плагин по-прежнему подходил для всего».
Однако избавление от зависимости выглядело настолько трудоёмкой задачей, что выпуск Gradle 3.0 сильно осложнил Вилкинсону жизнь. Это разозлило его настолько, что он не только написал на форуме Gradle пост с вопросом «как разработчикам плагинов быть в такой ситуации?», но и сослался на него в твиттере со словами «очередное о том бардаке, что называется внутренностями Gradle, хотя на деле торчит наружу».
С официального аккаунта Gradle ему пришёл реплай примерно такого содержания: «Да, хреново Извиняемся, что доставили столько боли. Опубликовали на форуме ответ».
В ответе на форуме Эрик Уэнделин (Gradle) извинился за «протёкшую абстракцию», после чего как озвучил конкретный план действий на текущий момент, так и пообещал в долгосрочной перспективе изменить ситуацию с публичными API в целом, активно обсуждая её с сообществом («это будет непросто, но мы не можем продолжать подход “наспех чинить каждый конкретный случай”»). Одной из причин возникновения проблем он считает смену версии Groovy, однако уточняет, что винить язык неправильно: «Мы должны были понимать, что переход на новую версии Groovy может сломать нам совместимость».
Прочитав ответ Уэнделина, Уилкинсон написал, что зря погорячился и высказался неконструктивно, а также что «обсуждать проблему с сообществом» звучит отлично, и он будет рад в этом поучаствовать. Ну будущее он предложил Gradle использовать в своих собственных плагинах исключительно публично доступные API: «понимаю, что это проще сказать, чем сделать, но если бы все собственные плагины Gradle были написаны лишь с публичными API, разработчикам других плагинов стало бы гораздо проще предоставлять схожую функциональность». Уэнделин согласился с тем, что это находится в корне проблемы, хотя это и «будет очень сложно распутать».
В общем, отработка негативного фидбэка у Gradle впечатляющая — до решения проблемы ещё далеко, а человек уже превратился из хейтера в лояльного пользователя.
