Организация проектных библиотек

Question

Я знаю, что это проблема, решенная давным-давно, но у меня возникают проблемы с поиском решения этой проблемы.

У меня есть многочастный проект следующим образом:

Native-Модуль (на основе C) -> Core (бизнес-логика, Java) -> UI / API-модуль / слой

Собственный модуль и модуль ядра останутся одинаковыми во всех вариантах. Тем не менее, уровень пользовательского интерфейса / API будет отличаться в зависимости от использования. При использовании в качестве настольного приложения это будет просто слой JavaFX или ReactNative. При использовании на сервере уровень UI / API будет уровнем, который будет взаимодействовать с управляющим сервером через REST.

Чтобы было ясно, все это уже построено и работает просто отлично. Но я импортировал / копировал библиотеку каждого модуля в следующий модуль вручную. Моя проблема в том, как мне управлять всеми отдельными модулями в git или gradle более автоматизированным способом? Мне также должно быть ясно, что, хотя я использую git и gradle и имею базовое понимание того и другого, мне не хватает знаний, чтобы справиться с этим самостоятельно. У меня есть отдельные настройки репозиториев для каждого модуля. Я знаком с подмодулем git, но, похоже, он не соответствует моим потребностям. Я пытаюсь все настроить так, чтобы у новых парней, начинающих работать над проектом, был простой процесс установки.

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

Answer 1

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

В общем, выходные данные сборки каждого модуля будутбыть развернутым как версионные артефакты (например, файлы jar) в хранилище (например, https://jfrog.com/artifactory/)), и ваши проекты будут определять зависимости от тех версионных артефактов, которые хранятся в хранилище. Затем система сборки (например, gradle) извлечет определенныйартефакты в вашей сборке автоматически. Вы сами настраиваете этот локальный репозиторий, такой как artifactory, и конфигурируете свою сборку gradle для просмотра в этом локальном репозитории артефактов, в дополнение к просмотру центральных репозиториев, где хранятся общие артефакты с открытым исходным кодом.

Это общий высокоуровневый подход. Подробно о том, как вы управляете этим в своей среде, я не могу здесь предоставить (например, я недостаточно знаком с gradle, чтобы дать содержательный конкретный ответ, используя его).

В качестве примера, который использует некоторые изтехнология, о которой вы упоминаете в своем вопросе (многомодульный проект с нативными библиотеками, Java-кодом и сборкой Gradle), система JavaFX имеет все это, и исходный код можно найти здесь https://github.com/javafxports/openjdk-jfx. Однако JavaFX является большим,сложный проект, который имеет собственные части, нацеленные на различные собственные системы (OS X, Windows, Linux) и ваше конкретное приложение, возможно, не потребуется столько настройки, как JavaFX. Тем не менее, возможно, вы могли бы что-то извлечь из рассмотрения того, как разработчики JavaFX решили эту проблему.

Еще одним соображением является разделение проблем между системой сборки и сгенерированными артефактами, системой развертывания и развернутыми службами. Для некоторых ваших компонентов вам может не потребоваться наличие зависимостей во время выполнения или компиляции через библиотеки, импортированные в систему управления зависимостями типа gradle. Вместо этого, как вы описываете в своем вопросе, у вас слабая связь через REST API, поэтому уровень пользовательского интерфейса фактически не зависит от времени компиляции на сервере. Таким образом, часть на основе REST может быть развернута на локальном сервере или на веб-службах Amazon, Google Cloud или Microsoft Azure. Если AWS, шаблон формирования облаков может быть использован для передачи службы в окно EC2 с помощью сценария Ansible. Автоматизация такого рода вещей выходит за рамки артефактов, мерзавцев, градлов и т. Д. И может довольно быстро усложниться и выходит за рамки того, о чем я был бы готов рассказать подробнее.