Gradle *

Управление зависимостями – одна из наиболее важных функций в арсенале систем сборки. С приходом Gradle в качестве основной системы сборки Android-проектов в части управления зависимостями произошёл существенный сдвиг, закончилась эпоха ручного копирования JAR-файлов и долгих танцев с бубном вокруг сбоящих конфигураций проекта.



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

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

Часто встречается ситуация когда необходимо использовать один и тот же код в разных проектах и при этом поддерживать его актуальность на каждом из них. В этой статье я покажу как можно вынести такой код в отдельные компоненты и использовать их через dependencies внутри build.gradle. Кроме общего кода так же будет рассмотрен пример с вынесением общих настроек build.gradle файла, кочующих из приложения в приложение.

Если у вас возникало отвращение при копировании одного и того же кода по проектам и желание как то это исправить, добро пожаловать под кат.

Разрабатывая наш Мобильный Банк мы однажды столкнулись с такой проблемой.

А именно: при использовании библиотеки GSON для сериализации/десериализации в/из JSON на некоторых устройствах от HTC в рантайме мы получали креш. Причина такого поведения в том, что некоторые устройства от HTC имеют в своей прошивке свою версию GSON, которая более старая чем та которую использовали мы в своих проектах. А андроидовский java class loader при загрузке класса в память предпочитает «системную» версию, вместо версии в проекте.

Кроме того на некоторых устройствах существует аналогичная проблема с OkHttp — тоже довольно популярной библиотекой в мире андроид разработки.

Для решения проблемы необходимо переупаковать GSON (или любую другую библиотеку) с помощью утилиты JarJar. После переупаковки артефакт будет иметь новую структуру пакетов, которую необходимо использовать в директивах импорта в своем проекте. Для этого нужно подключить переупакованный jar к своему проекту вместо исходного.

Нам захотелось автоматизировать эту задачу и в итоге появился Gradle JarJar Plugin, доступный в Maven Central. Плагин позволяет указать jar-библиотеки и правила для переупаковки их с помощью JarJar.

Наконец-то я созрел, чтобы начать свой веб-проект. Очередной todo-менеджер, который агрегирует задачи с нужных мне источников. Планировался как проект для души, такой чистый и правильный. Никаких компромиссов в архитектуре и технологиях. Только best-practices, только хардкор. И, конечно же, кнопать это все собрался в любимой Intellij IDEA.

После 7 лет Java, последних двух вперемешку с Scala, захотелось попробовать Groovy. Для сборки, конечно же Gradle — популярно и удобно. Рельсы показались слишком «заезженные», так что решил использовать Spring для веб, причем по современному, через Spring Boot. И все было просто замечательно, только с ORM не сложилось. На работе мы Hibernate выпилили, заказчик лично невзлюбил (не смейтесь и такое бывает — отдельная история) и заменили своим велосипедом. Негативный опыт и нежелание тянуть монстра ради пары сущностей сделали свое — хибернейту твердое нет! Захотелось попробовать что-то совсем другое. По воле случая наткнулся на Ebean, который и был выбран.

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

Скажу сразу — в Gradle я совсем новичок.
Пол рабочего дня, вместо того, чтоб писать код содержащий мою семью, я потратил на то, чтобы узнать что из 150-ти строк конфига, надо было исправить одну, поменяв classpath 'com.jakewharton.sdkmanager:gradle-plugin:+ на com.jakewharton.sdkmanager:gradle-plugin:0.10.1.
Программа вчера запускалась а сегодня перестала. А знаете что я сегодня сделал не так? А ничего. Абсолютно тот же код и те же конфиги. Ни одного файла не менял.
Смышленый или опытный программист уже догадался что знак "+" — значит что надо загрузить самую последнюю версию библиотеки и загрузилось что то не то. Да это часть проблемы, но не вся. Сама библиотека ничего не портила. Она просто имела зависимость от другой — которая портила.
Да и вообще, что за мода выкладывать не оттестированные библиотеки в общий репозиторий? При Мавене такого не было!

Очень много статей о Gradle написано. И со своей стороны хотелось бы добавить в копилку такую пошаговую инструкцию, прочтение которой, я надеюсь, позволит тем, кто плохо знаком с Gradle, “распробовать” и продолжить самостоятельно изучать этот инструмент.

Данная статья не будет подробно описывать такие темы, как плагины gradle (plugin), задачи (task), зависимости (dependencies), автоматическое тестирование и прочие прелести этого сборщика проектов. Во-первых, каждая тема заслуживает отдельной статьи или даже серии статей, а во-вторых, на эти темы уже есть статьи на хабре, например: Gradle: Tasks Are Code, Gradle: Better Way To Build. А еще на официальном сайте Gradle есть прекрасно написанный Gradle User Guide. Я же cфокусирую внимание на непосредственном решении поставленной задачи, и все сопутствующие темы будут описаны в рамках этой самой задачи.
Сначала определимся с целью, что же мы хотим получить на выходе? А цель указана в заголовке статьи. Мы хотим получить проект с несколькими модулями, который собирается с помощью Gradle. И так, приступим.

При сборке проектов для Android Gradle позволяет указать некоторые параметры, позволяющие собрать и подписать пакет, готовый для загрузки в Google Play. Однако, вряд ли стоит загружать некоторые данные, такие как пароль от приватного ключа в публичный репозиторий. В статье, перевод которой ниже, автор рассматривает способы ввода приватной информации, такой как пароли, во время сборки проекта.

Gradle позволяет получить доступ к консоли с помощью метода System.console(). Консоль предоставляет метод для чтения паролей, поэтому для ввода пароля можно использовать:

def password = System.console().readPassword("\nPlease enter key passphrase: ")

Теперь можно использовать пароль в любом месте скрипта сборки, и все готово… ой, тогда это будет слишком короткий пост, поэтому теперь поговорим о проблемах.

В продолжение предыдущей статьи про развертывание Ratpack приложения на Heroku, сегодня я расскажу про использования плагина Gradle. Это был трудный опыт по развертыванию простого Ratpack приложения на Heroku PaaS. Мы рылись в хитросплетениях buildpack's для развертывания на Heroku.Хорошие новости в том, что это бельше не обязательно.
В этой статье я покажу более простой способ развертывания. В этом методе не необходимости явно использовать Heroku Toolbelt и custom'ые buildpack's. Так же больше не нужно иметь Ruby, RVM, или множество других связанных с Ruby технологий, которые не нужны Java/Groovy разработчикам, им даже знать об этот нет необходимости.

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

После не самого удачного, на мой взгляд, эксперимента по сборке flex с использованием maven (подробности тут), решил попробовать gradle, про который пишут, что он взял лучшее от ant и maven и это следующий шаг в развитии. Решил провести эксперимент по такому плану:

• flex compile (Path to FlexSDK/maven dependency)
• as3 compile
• flex unit run (dependency)
• fla compile as static resource
• reliase compress
• code quality (FlexPMD)
• multy module project

Кому интересно, что из этого получилось, прошу под кат, потому как текста достаточно много. Он писался прямо по ходу эксперимента, если читать совсем лень, то в конце есть ссылка на тестовый проект.

В данной заметке я покажу, как запускать DBDeploy из скрипта Gradle.

О чём это вообще?

Возможно, вы уже слышали о версионированной миграции структуры баз данных. Об этом писали на хабре. DBDeploy — один из самых простых и известных инструментов, позволяющий легко установить все последние изменения в базе данных на любом инстансе и любой девелоперской машине. А Gradle — модный ныне инструмент для сборки проекта (как Ant и Maven, только лучше). О нём тоже уже писали.

И в чём вопрос?

Вопрос в том, как запускать DBDeploy из скрипта Gradle? У DBDeploy есть таски для Ant и плагин для Maven, но пока ещё нет плагина для DBdeploy (точнее, он в зачаточном состоянии). Немного потыркавшись, я пришёл к выводу, что самый простой способ — это использовать тот самый Ant таск DBDeploy из скрипта Gradle (здесь описано, как из gradle-скрипта использовать любые Ant-таски). Рассмотрим пример.

В предыдущем топике я постарался вкратце рассказать, что же такое 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.