[devel] xgradle плагин - новый способ сборки

[Ivan Khanas]

Создана первая версия плагина для системы сборки gradle.
Плагин позволяет разрешать зависимости используя присутствующие в 
системе артефакты (jar и pom файлы).
В перспективе это может помочь избавиться от вендоринга зависимостей при 
сборке пакетов например таких как:

linstor - https://packages.altlinux.org/ru/sisyphus/srpms/linstor/
apache-kafka - https://packages.altlinux.org/ru/sisyphus/srpms/kafka/
opensearch - https://packages.altlinux.org/ru/sisyphus/srpms/opensearch/

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

СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ

Init скрипт плагина устанавливается в директорию с init скриптами 
системы сборки gradle (gradle/init.d), jar файл устанавливается в 
директорию плагинов gradle (gradle/lib/plugins). При запуске сборки 
плагин воздействует на стратегию разрешения зависимостей и на 
конфигурацию. Это позволяет разрешать зависимости с использованием 
системных артефактов. Всё что надо будет сделать пользователю, это 
поставить соответствующий rpm пакет в сборочное окружение.


      Принцип работы

На директорию содержащую jar файлы устанавливается flatDir репозиторий 
для поиска необходимых jar файлов. Так как структура файловой системы 
дистрибутива Linux сильно разнится с архитектурой maven или ivy 
репозиториев, у нее нет такого уровня вложенности и паковать библиотеки 
на java во что-то на подобии 
(/usr/share/java/org/xmlunit/xmlunit-assertj3/2.10.3/xmlunit-assertj3-2.10.3.jar) 
никто не хочет. Плагин решает и эту проблему установкой flatDir 
репозитория с контролируемой глубиной рекурсивного обхода по уровням 
(сейчас стоит 3). Также у сопровождающих бывают идеи о переименовывании 
jar файлов или pom файлов. Плагин позволяет переименовывать файлы при 
соблюдении некоторых условий.

Сама стратегия разрешения использует некоторую эвристику, например для 
зависимости вида: org.junit.jupiter:junit-jupiter генерируются варианты 
имен pom файла -> находится потенциальный pom -> находится валидный pom 
-> ищется jar файл по artifactId -> подхватываются все транзитивные 
зависимости -> для каждой из них выполняется то же самое -> в конце 
недостающие зависимости добавляются в конфигурацию.

Система сборки gradle не разрешает несоответствие версий, то есть в 
ситуации когда в системе находится модуль, чья версия не соответствует 
запрашиваемой, то gradle обращается к кэшу и происходит ошибка. Теперь 
же на этапе конфигурации происходит подстановка версии (запрашиваемой на 
системную)

Пример: Override version: org.assertj:assertj-core:3.25.1 -> 3.19.0

Также плагин умеет работать с BOM (Bill-of-Materials) файлами (разрешать 
и удалять их из конфигурации)
Транзитивными зависимостями (каждая добавляется в соответствии с ее scope)


      Достоинства предлагаемого улучшения:

На данный момент java проекты, которые используют gradle в качестве 
системы сборки собираются просто выкачиванием откомпилированных в 
byte-code артефактов (вендорингом).

Итак, плагин позволяет:

Cобирать Java-проекты в полностью офлайн-режиме, используя только 
системные артефакты, без обращения к внешним репозиториям.

Существенно упрощает интеграцию Gradle-проектов в процесс сборки 
дистрибутива, делая его воспроизводимым, прозрачным и независимым от 
сторонних ресурсов.

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

Совместим с типовой организацией библиотек в Linux-дистрибутивах 
(например, /usr/share/java) без необходимости имитировать структуру Maven.

Облегчает работу мейнтейнеров и сборочных систем, снижая барьер на 
добавление и обновление Java-пакетов в дистрибутиве (форсирование версий).

Плагин называется xgradle - https://altlinux.space/ALTLinux/xgradle


Это только первая версия, прошу мейнтейнеров с опытом написать свое 
мнение, оценку моей идее.
Собираюсь добавить maven-model для парсинга pom файлов и построения 
графа зависимостей вместо того, чтобы сваливать их в общую кучу.

  Также работать над логикой правильного добавления в конфигурацию 
зависимостей.

----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20250802/4d87408e/attachment.html>