<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div id="issue_description_wiki" class="wiki">
<p>Создана первая версия плагина для системы сборки gradle.<br>
Плагин позволяет разрешать зависимости используя присутствующие
в системе артефакты (jar и pom файлы).<br>
В перспективе это может помочь избавиться от вендоринга
зависимостей при сборке пакетов например таких как:</p>
<p>linstor - <a class="moz-txt-link-freetext"
href="https://packages.altlinux.org/ru/sisyphus/srpms/linstor/">https://packages.altlinux.org/ru/sisyphus/srpms/linstor/</a><br>
apache-kafka - <a class="moz-txt-link-freetext"
href="https://packages.altlinux.org/ru/sisyphus/srpms/kafka/">https://packages.altlinux.org/ru/sisyphus/srpms/kafka/</a><br>
opensearch - <a class="moz-txt-link-freetext"
href="https://packages.altlinux.org/ru/sisyphus/srpms/opensearch/">https://packages.altlinux.org/ru/sisyphus/srpms/opensearch/</a></p>
<p>также можно будет собрать проекты по типу spring-framework,
поскольку они переходят на gradle в связи с его удобством для
крупных проектов. </p>
<p>СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ</p>
<p>Init скрипт плагина устанавливается в директорию с init
скриптами системы сборки gradle (gradle/init.d), jar файл
устанавливается в директорию плагинов gradle
(gradle/lib/plugins). При запуске сборки плагин воздействует на
стратегию разрешения зависимостей и на конфигурацию. Это
позволяет разрешать зависимости с использованием системных
артефактов. Всё что надо будет сделать пользователю, это
поставить соответствующий rpm пакет в сборочное окружение.</p>
<h3>Принцип работы</h3>
<p>На директорию содержащую 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 файлов. Плагин позволяет
переименовывать файлы при соблюдении некоторых условий.</p>
<p>Сама стратегия разрешения использует некоторую эвристику,
например для зависимости вида: org.junit.jupiter:junit-jupiter
генерируются варианты имен pom файла -> находится
потенциальный pom -> находится валидный pom -> ищется jar
файл по artifactId -> подхватываются все транзитивные
зависимости -> для каждой из них выполняется то же самое
-> в конце недостающие зависимости добавляются в
конфигурацию.</p>
<p>Система сборки gradle не разрешает несоответствие версий, то
есть в ситуации когда в системе находится модуль, чья версия не
соответствует запрашиваемой, то gradle обращается к кэшу и
происходит ошибка. Теперь же на этапе конфигурации происходит
подстановка версии (запрашиваемой на системную)</p>
<p>Пример: Override version: org.assertj:assertj-core:3.25.1 ->
3.19.0</p>
<p>Также плагин умеет работать с BOM (Bill-of-Materials) файлами
(разрешать и удалять их из конфигурации)<br>
Транзитивными зависимостями (каждая добавляется в соответствии с
ее scope)</p>
<h3>Достоинства предлагаемого улучшения:</h3>
<p>На данный момент java проекты, которые используют gradle в
качестве системы сборки собираются просто выкачиванием
откомпилированных в byte-code артефактов (вендорингом).</p>
<p>Итак, плагин позволяет:</p>
<p>Cобирать Java-проекты в полностью офлайн-режиме, используя
только системные артефакты, без обращения к внешним
репозиториям.</p>
<p>Существенно упрощает интеграцию Gradle-проектов в процесс
сборки дистрибутива, делая его воспроизводимым, прозрачным и
независимым от сторонних ресурсов.</p>
<p>Избавляет от необходимости вендоринга зависимостей, тем самым
уменьшая дублирование, объем исходных пакетов и потенциальные
проблемы с лицензированием.</p>
<p>Совместим с типовой организацией библиотек в
Linux-дистрибутивах (например, /usr/share/java) без
необходимости имитировать структуру Maven.</p>
<p>Облегчает работу мейнтейнеров и сборочных систем, снижая барьер
на добавление и обновление Java-пакетов в дистрибутиве
(форсирование версий).</p>
<p>Плагин называется <span style="">xgradle - <a
class="moz-txt-link-freetext"
href="https://altlinux.space/ALTLinux/xgradle">https://altlinux.space/ALTLinux/xgradle</a><br>
<br>
<br>
Это только первая версия, прошу мейнтейнеров с опытом написать
свое мнение, оценку моей идее. <br>
Собираюсь добавить maven-model для парсинга pom файлов и
построения графа зависимостей вместо того, чтобы сваливать их
в общую кучу. </span></p>
<p><span style=""> Также работать над логикой правильного
добавления в конфигурацию зависимостей.</span></p>
</div>
<p><br>
</p>
</body>
</html>