Как подключить развертывание совместно используемого объекта linux libXy.so к зависимости gradle

Question

Я привожу в порядок цепочку CI между скомпилированным C / C ++ общим объектом (.so) и заданием сборки gradle, которое принимает общий объект, используя некоторую форму привязки для взаимодействия с оборудованием, во встроенной среде в стиле linux / kiosk , Мой клиент использует aws, включая репозитории maven для публикации своих зависимостей java.

Компонент # 1 - компонент C / C ++ .so libXY.so >> вывод

Компонент № 2 - Java-компонент, построенный под Gradle вход << libXY.so </p>

У меня есть конвейер bitbucket, правильно генерирующий общий объект. Я не знаю, как развернуть его, используя передовой опыт. Текущий процесс, который явно следует плохой практике и который предшествует мне, состоит в том, чтобы скомпилировать libXY.so на компьютере разработчика и git добавить libXY.so в папку внутри компонента # 2. Как только libXY.so вставлен в git git в компонент # 2, остальная часть системы CI запускается и запускает модульные тесты и т. Д., И в случае успеха генерирует артефакт.

пример конвейера bitbucket для добавления компонента libYX.so в систему CI

pipelines:
  default:
    - step:
        name: Build
        image: atlassian/default-image:2
        caches:
          - YYXX
        script:
          - apt update
          - apt install cmake libabc-dev libcba-dev -y
          - cmake ..
          - make
        artifacts:
          - libXY.so
    - step:
        name: Publish
        image: atlassian/pipelines-awscli  # maybe maven?
        trigger: manual
        script:
          - echo "TODO make publish to maven / aws s3 ???"

definitions:
  caches:
    YYXX: /opt/custom_libs

Часть компонента # 2 build.gradle, извлекающая зависимости удаленно, но не libXY.so. Зависимости com.CustomerName уже извлекаются из частных репозиториев aws maven, что, как мне кажется, я должен имитировать. com.CustomerName: имя javalibname отображается в папку aws

com / CustomerName / javalibname с maven-metadata.xml, а затем папки для версий

dependencies {
    compile group: 'com.CustomerName', name:'customerjavaapp', version:"${customerjavaappVersion}"
    compile group: 'org.openmuc', name: 'jrxtx', version: '1.0.1'
    compile 'org.json:json:20180813'
    compile 'xuggle:xuggle-xuggler:5.4'
    compile "com.CustomerName:javalibname:1.3.2-4"
    compile group: 'net.java.dev.jna', name: 'jna', version: '5.0.0'
    testCompile group: 'junit', name: 'junit', version: '4.12'
    testCompile group: 'org.mockito', name: 'mockito-core', version: '2.10.0'
}

Часть компонента # 2 build.gradle Код, который, я считаю, копирует в общий объект, расположенный в репозитории кода, для развертывания внутри .jar

distributions {
    main {
        contents {
            into("CustomerName"){
                from "CustomerName/settings1.conf"
                from "CustomerName/settings1.conf"
            }
            into("deps"){
                from "shared/libXY.so"
            }
            from "CHANGELOG.md"
        }
    }   
}

Я ожидаю построить конвейер bitbucket для компонента # 1, чтобы опубликовать libXY.so в репозиторий maven, размещенный на aws, а затем изменить build.gradle для его получения