Gradle *

Предыстория

Иногда, когда я прокрастинирую, я занимаюсь уборкой: чищу стол, раскладываю вещи, прибираюсь в комнате. По сути, привожу окружающую среду в порядок — это заряжает энергией и настраивает на рабочий лад. С программированием у меня та же ситуация, только я чищу проект: провожу рефакторинги, делаю различные инструменты и всячески стараюсь упростить жизнь себе и коллегам.

Некоторое время назад мы в команде Android решили сделать один из наших проектов — Кошелек — многомодульным. Это привело как к ряду преимуществ, так и проблем, одна из которых — необходимость конфигурировать каждый модуль заново. Конечно, можно просто копировать конфигурацию из модуля в модуль, но если мы захотим что-то поменять, то придется перебрать все модули.

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

Привет, Хаброжители! На днях начал изучать GitHub Actions для Android. Ранее у меня была удачная попытка настройки данного функционала для проекта на Flutter, но без деплоя, для которого полно информации и гайдов как на англоязычных ресурсах, так и на русскоязычных, а вот с нативным андроидом не всё так прозаично. И решил записать основные проблемы и их решение.

Этап первый: настройка для автоматической подписи готового apk

Первая проблема с которой я столкнулся, это сделать универсальную настройку, позволяющую собирать релизные варианты как локально, так и глобально.

Я использую вариант с использование файла keystore.properties, который позволяет нам добавить ключ разработчика в папку проекта, не светя при этом паролями от него, делается это так:

В этой статье предлагаю Вашему вниманию инструкцию по установке и настройке TeamCity для автоматизации сборки и тестирования Android проектов под Windows.

Также буду уделять внимание особенностям настройки environment’а под Android проект (которые находил в процессе исследования) и различного рода вещам, которые могут помочь облегчить жизнь начинающему тестировщику и разработчику.

Цели:

При обновлении кода проекта должно происходить:

• Автоматическая сборка проекта
• Прогон UI автотестов
• Экспорт APK файлов debug и release для последующего ручного тестирования
• Уведомление всех участников команды разработки о результатах

План:

1. Установка и настройка Java JDK
2. Установка и настройка Android SDK
3. Установка отдельного Gradle для дебага
4. Подготовка Android проекта
5. Установка TeamCity Server и Build Agent
6. Настройка TeamCity Project → Build для билда проекта и получения установочного APK
7. Настройка build steps c UI автотестами

Допустим, наше Java приложение размещено на платформе "Heroku", и ему требуется подключиться к HTTP серверу, требующему предоставление Клиентского Сертификата.

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

В данной статье я хочу подробно рассмотреть процесс публикации с нуля Java артефакта через Github Actions в Sonatype Maven Central Repository используя сборщик Gradle.

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

В нашем офисе состоялась традиционная встреча бэкенд-разработчиков — митап Java Jam.

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

Для тех, кто хотел посетить митап, но не смог, а также для всех желающих узнать опыт Яндекс.Денег и эксперта Hazelcast, видео трех докладов — под катом.

Разработчики облегчают жизнь людям, а Gradle — разработчикам. Если вы пишете на Android, эта статья для вас. Читайте о том, что за зверь этот Gradle (спойлер: он слон), а также — как с ним работать.

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

В своей статье хочу рассказать об очередной хитрости, которую можно довольно просто реализовать с помощью Gradle — переупаковке пакетов библиотек. Каждый, кто хоть чуть чуть работал с этой системой сборки, знает, что она автоматически умеет решать конфликты разных версий библиотек, а при желании можно повлиять на это, например зафорсить конкретную версию какой-нибудь библиотеки:

configurations.all {
    resolutionStrategy {
        force "org.ow2.asm:asm:7.2"
    }
}

К сожалению, это не всегда помогает решить проблему конфликта версий. Например, есть известная проблема, что некоторые устройства htc в прошивке уже имеют библиотеку gson и если ваша версия gson-а отличается от встроенной, то могут возникнуть проблемы, так как ClassLoader загрузит в память только один класс и в данном случае это будет системный.

Такая проблема также может возникнуть и при разработке библиотек. Если вы подключите в свой проект 2 библиотеки, использующие одну и ту же стороннюю библиотеку разных версий, например 1 и 2, то Gradle разрулит и возьмет самую новую версию, вторую. Но если в этой сторонней библиотеке нет обратной совместимости и вторая версия не может быть просто так использована вместо первой, то будут проблемы, которые наверняка будет очень сложно отследить по стектрейсу. Библиотека, ожидающая первую версию, получит классы второй и просто упадет.

Я столкнулся с конфликтом версий при написании градл плагина, в нем используется библиотека asm, которая и конфликтовала. После написания плагина, я проверил его работоспособность на тестовом проекте: все отлично, проверил на pet project-е, тоже все хорошо, но когда подключил к реальному рабочему проекту с кучей сторонних зависимостей, столкнулся с проблемой.

Решение проблемы под катом.

• Первая часть
• Пример на Github

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

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

Во-вторых, в трансформируемом .class файле для всех полей с аннотацией @State нужно явно определить тип, чтобы вызвать соответствующий метод у бандла для сохранения/восстановления состояния, а точно определить тип можно лишь проанализировав всех родителей класса и реализуемые ими интерфейсы.

Таким образом, нужно просто иметь возможность анализировать абстрактно синтаксическое дерево трансформируемых файлов.

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

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

Этот небольшой пост может оказаться полезен тем, кто хотел бы быстро начать работать с LLVM, не заморачиваясь с закачкой исходников и построением фреймворка. Кто не хотел бы ковыряться в малопонятных скриптах CMake-а, чтобы добиться ожидаемого результата, ну и наконец, просто для ленивых :)

Я расскажу, как сделать это изящно, буквально парой строк в билд-скрипте Gradle-а.

• Вторая часть

Вместо вступления

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

Решив сделать что-то, приближенное к реальному миру Android разработки, написал плагин, который парсит layout xml файлы разметки и создает по ним Java объект со ссылками на вьюхи. Затем побаловался с трансформацией манифеста приложения (того требовала реальная задача на рабочем проекте), так как после трансформации манифест занимал порядка 5к строк, а работать в IDE с таким xml файлом довольно тяжело.

Так я разобрался как генерировать код и ресурсы для Android проекта, но со временем захотелось чего-то большего. Появилась мысль, что было бы круто трансформировать AST (Abstract Syntax Tree) в compile time как это делает Groovy из-под коробки. Такое метапрограммирование открывает много возможностей, была бы фантазия.

Дабы теория не была просто теорией, я решил подкреплять изучение темы созданием чего-то полезного для Android разработки. Первое, что пришло на ум — сохранение состояния при пересоздании системных компонентов. Грубо говоря, сохранение переменных в Bundle максимально простым способом с минимальным бойлерплейтом.

Вступление

Статья пишется с прицелом на нативные андроид проекты, но, так как градл универсальная система сборки, в принципе, подойдет и для других проектов, которые может собрать градл. Идея не моя, я ее подчерпнул из гитхаб проекта у Jake Wharton SdkSearch — набор программ для поиска по документации андроид сдк.

Предисловие

Из далекого 2012, на просторах Хабра мне запомнился коммент:

… если нет корпуса с самого начала, то устройство так и останется
недоделанным, ляжет пылиться на полке...

Топик далеко не про хардварную составляющую. Разбирая свою проблему, я убедился в верности сия суждения и постарался навести порядок на своей пыльной полке.

Недавно ко мне обратился заказчик, который попросил добавить в его проект поддержку нескольких сервисов. Задача заключалась в том, что мне нужно было подключить сервис "А" и перед выкладкой приложения в продакшн, обкатать этот сервис на тестовом окружении. Я решил проанализировать свои предыдущие решения и… ужаснулся. 

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

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

Как мне кажется, большинство людей начинают разбираться с gradle только тогда, когда в проекте что-то надо добавить или что-то внезапно ломается — и после решения проблемы "нажитый непосильным трудом" опыт благополучно забывается. Причём многие примеры в интернете похожи на ускоспециализированные заклинания, не добавляющие понимания происходящего:

android {
    compileSdkVersion 28
    defaultConfig {
        applicationId "com.habr.hello"
        minSdkVersion 20
        targetSdkVersion 28
    }
    buildTypes {
        release {
            minifyEnabled false
        }
    }
}

Я не собираюсь подробно описывать, для чего нужна каждая строчка выше — это частные детали реализации андроид-плагина. Есть кое-что более ценное — понимание того, как всё организовано. Информация раскидана по различным сайтам/официальной документации/исходникам градла и плагинов к нему — в общем, это чуть более универсальное знание, которое не хочется забывать.

Дальнейший текст можно рассматривать как шпаргалку для тех, кто только осваивает gradle или уже забыл.

Рады пригласить всех интересующихся java-разработкой на очередной открытый DINS Java EVENING, который пройдет в нашем офисе на Старо-Петергофском, 19.

На встрече мы познакомимся с опытом TextBack и узнаем, как проходит их миграция с Vert.x на Spring. Коллега из Genestack поделится своим опытом построения билд-системы на Gradle в большом проекте с нуля.

Под катом — подробнее о докладах и спикерах, ссылка на регистрацию для участия во встрече.

Достаточно часто в моей практике используется связка Spring + Angular. Хочу поделится своим опытом по подготовке подобного проекта в среде разработки IntelliJ IDEA.

Создаем пустой Gradle проект

Для начала создадим пустой Gradle проект в IDEA, при этом снимите все галочки библиотек и фреймворков.

Пусть наш артефакт будет «demo», а группа «com.habr». После создания проекта будет автоматически сгенерировано файлы settings.gradle и build.gradle со следующим содержанием:

Статья про тестирование взаимодействия с БД в CI. Я видел несколько решений использующих docker и testcontainers, но у меня есть своё и им я хочу поделиться.

Для Scala проектов довольно распространённым является предоставление бинарных артефактов скомпилированных под несколько версий Scala компилятора. Как правило для целей создания нескольких версий одного артефакта в сообществе принято использовать SBT, где эта возможность есть прямо из коробки и настраивается в пару строк. Но что если мы хотим заморочится и создать билд для кросс компиляции не используя SBT?

Для одного из своих Java проектов я решил создать Scala фасад. Исторически весь проект собирается с помощью Gradle, и фасад было решено добавить в этот же самый проект в качестве сабмодуля. Gradle в целом может компилировать Scala модули с той лишь оговоркой что никакой кросс компиляции в поддержке не заявлено. Есть открытый тикет 2017 года и пара плагинов (1, 2), которые обещают добавить эту возможность в ваш проект, но с ними есть проблемы, как правило связанные с публикацией артефактов. И больше в целом ничего нет. Я решил проверить, как сложно на самом деле сконфирурировать билд для кросс компиляции без специальных плагинов и СМС.