Gradle *

Всем привет! Наверняка каждый Android-разработчик хоть раз сталкивался с проблемой скорости сборки своего проекта. После нехороших слов в адрес кодогенерации, покупок более мощного железа, многочисленных попыток распилить проект на небольшие параллельно собираемые модули и прохождений всех стадий торга мы продолжаем искать решение этой проблемы. К счастью, за годы развития и в Gradle, и Android Gradle Plugin (AGP) появилось много полезных штук для ускорения сборки, о которых я расскажу дальше.

Несмотря на шутку в адрес многомодульности, это действительно полезный подход, но для большого проекта с богатой историей модуляризация может быть очень сложным процессом. Поэтому пока давайте посмотрим, что можно сделать без больших болей на уровне Gradle и AGP.

Я расскажу на примере мобильного Яндекс Браузера. У нас было ~150 Gradle-модулей, ~2 млн LoC на Java/Kotlin, десяток Gradle-плагинов, тысячи строк кода в buildSrc и лёгкая дрожь от вопроса, сколько ещё может переварить билд-система. Не скажу, что это всё было категорически необходимо, но к написанным строчкам кода надо проявлять уважение.

Привет, Хабр! Летом я выступал на Summer Droid Meetup с докладом про сборку Android-приложения. Видеоверсию можно найти здесь: habr.com/ru/company/funcorp/blog/462825. А для тех, кто больше любит читать, я как раз и написал эту статью.

Речь пойдёт о том, что же это такое — Android-приложение. Мы соберём разными способами Hello, world!: начнём с консоли и посмотрим, что вообще происходит под капотом систем сборки, потом вернёмся немного в прошлое, вспомним про Maven и изучим современные решения Bazel и Buck. И, наконец, всё это сравним.

Привет! Традиционно рассказываем, что нового в IntelliJ IDEA 2019.2. Список большой и все равно неполный: если хочется подробностей, добро пожаловать на страницу What’s new in IntelliJ IDEA 2019.2.

Это – обзор нового в IntelliJ IDEA 2019.1. Ссылки в заголовках ведут на соотвествующие разделы на сайте, где всё описано детально, но на английском.

В процессе разработки CUBA мы применяли все три основных инструмента сборки — начали с Ant, потом перешли на Maven на короткое время, а сейчас используем Gradle и, похоже, что в ближайшее время останемся с ним.

Не так давно вышел Gradle 5.0. В этой версии появилось большое количество новых возможностей, которые помогут разработчикам писать более сложные сценарии и собирать свои проекты ещё быстрее и безболезненнее.

Здравствуйте, уважаемые хабравчане! Сегодня я хотел бы рассказать о том, как «скормить» Java-приложение докеру, как при этом лучше действовать, а чего делать не стоит. Я занимаюсь разработкой на Java более 10 лет, и последние года три провёл в самом тесном общении с Docker, так что у меня сложилось определённое представление о том, что он может и чего не может. Но ведь гипотезы надо проверять на практике, не так ли?

Я представил весь процесс как старую добрую компьютерную игру с тёплым ламповым пиксель-артом.

Начнем мы, как и полагается любой игре, с некоторого брифинга. В качестве вводной возьмем немного рекламы докера.

На сайте докера можно ознакомиться с рядом рекламных посулов – а именно, с обещанием увеличить скорость разработки и развертывания аж в 13 раз и повысить портативность в разработке (в частности, избавиться о сакраментального «работает на моей машине»). Но соответствует ли это реальности?

Сейчас мы попробуем доказать/опровергнуть эти утверждения.

Привет, Хабр! Настало время, когда можно сказать, что «new build system» Gradle является стандартом отрасли Android-разработки. Инструмент сделан настолько просто и удобно, что большинство разработчиков не испытает трудностей, даже не зная, как он устроен, и какие дополнительные возможности в нём есть — возникающие проблемы легко решаются с помощью 5 минут на StackOverflow, путем копирования «магического кода» в конфигурационные файлы. Возможно, в том числе из-за этого не все разработчики изучают Gradle детально и не знают о многих его полезных возможностях, которые существенно облегчают жизнь.

В предыдущем топике я постарался вкратце рассказать, что же такое Gradle и на каких идеях он построен. Также была освещена концепция Source Sets и функциональность, с ней связанная.

Теперь я хотел бы рассказать о том, чем Gradle зацепил лично меня. Речь пойдёт о способах работы с задачами. Задача в Gradle — близкий аналог Ant Target. И, чтобы не путаться в терминах, под задачей (или task) далее по тексту всегда будет подразумеваться Gradle Task. Если речь будет идти о сущности из Ant, то это будет указано явно: Ant task.

Так вот, задачи в Gradle создаются при помощи специального dsl (domain specific language) на основе Groovy. И возможности, которые этот dsl предоставлет, на мой взгляд, почти безграничны в сравнении с ant или maven.

Ни один проект с использованием платформы Java (и не только) не обходится без инструментов сборки (если только это не «Hello, world!»). Рано или поздно, но собирать дистрибутив руками надоедает. Да и компилировать из консоли было бы неплохо, если в проекте используется несколько разных IDE. А перед сборкой дистрибутива было бы здорово проставить номер версии в его имени. И unit тесты прогнать — не зря же Kent Beck книжки пишет. А там и Continues Integration на горизонте маячит. И здорово было бы научить CI сервер это все делать самостоятельно. Одним словом, есть уйма задач.

Раз есть задачи, то есть и решения. Думаю, большинство разработчиков хоть раз, но сталкивались с Ant. Очень многие используют Maven. Есть другие, не такие распространённые инструменты: GAnt, Buildr, и др. Каждый из них обладает набором своих плюсов и минусов, но сегодня я хочу представить вам кое-что новенькое. Gradle.