Проблема:
Наши скрипты Gradle работают нормально, если мы позволяем Gradle работать напрямую с собственным хранилищем плагинов.Когда мы направляем их через Apache Archiva, плагины не обнаруживаются, хотя мы настроили прокси-коннекторы Archiva.
Мы видим, что Archiva действительно выполняет прокси-сервер и кэширует то, что получило из хранилища плагинов Gradle,который только пом, без банки.Единственный найденный нами обходной путь - вручную загрузить пустой jar-файл с теми же координатами и именем, что и pom, после попытки проксирования (неудачной) один раз.
Похоже, это связано с тем, что делает Apache Archiva или какон настроен - кажется, что он не обрабатывает артефакты "jarless" (только pom).Есть ли способ исправить это?
Наша установка:
- Мы используем Gradle (5.1.1) в качестве инструмента сборки и нам нравится применять плагиныиспользуя подход плагинов {...}.
- Мы мигрируем из Apache Archiva, но все еще будем на нем некоторое время.Версия, которую мы используем, старая - v1.3.5, но я не уверен, будет ли новая версия лучше.
- Мы настраиваем только нашу Apache Archiva в качестве репозитория для наших скриптов Gradle.Они не могут получить доступ к собственным репозиториям плагинов Gradle на https://plugins.gradle.org/m2/. Даже если это возможно, мы предпочитаем прокси-сервер для производительности сборки.
Фон для считывателей не Gradle:
Когда Gradle настроен на применение плагина с идентификатором 'foo.bar', он обычно смотрит на репо https://plugins.gradle.org/m2/ для "артефакта maven" с идентификатором группы "идентификатор плагина "и идентификатор артефакта" идентификатор плагина .gradle.plugin "-" foo.bar "и" foo.bar.gradle.plugin" в этом случае.Вот фактический пример этого:
https://plugins.gradle.org/m2/com/cisco/filesystem/com.cisco.filesystem.gradle.plugin/1.4/
Там, для каждой версии, можно найти только файл pom (не jar).Этот pom-файл имеет единственную зависимость, которая действует как своего рода перенаправление на реальные координаты maven реального плагина.