Closed vityaman closed 2 months ago
думаю нужно посмотреть как принято называть модули в таких проекта. потому что точно нужно будет вынести common модуль (#35). там есть какие-то приколы с именованием Kotlin-модулей в мультиплатформенной сборке
GPT предлагает такой вариант:
- my_repository/
- common/
- src/
- commonMain/ // Общий код для всех платформ
- commonJvm/ // Код, специфичный для JVM
- commonAndroid/ // Код, специфичный для Android
- commonIOS/ // Код, специфичный для iOS
- mobile_app/
- src/
- mobileMain/ // Код для мобильного приложения
- mobileAndroid/ // Код, специфичный для Android мобильного приложения
- backend_app/
- src/
- backendMain/ // Код для backend приложения
- backendJvm/ // Код, специфичный для JVM backend приложения
- log_service/
- src/
- logMain/ // Код для сервиса логов
- logJvm/ // Код, специфичный для JVM сервиса логов
Понятно, что нужно еще поискать как это делают и тут не все сервисы
https://kotlinlang.org/docs/multiplatform-dsl-reference.html
Мне удалось собрать проект с помощью Gradle
, в котором 3 модуля: frontend (Android)
, backend (Ktor)
и shared (Java Library)
. Также подключил линтер Detekt
во frontend
и backend
. Для Detekt
приходится добавлять плагин, плагин для форматирования и кофигурацию в build.gradle.kts
каждого модуля. Это так, потому что мне не удалось завезти buildSrc
- там боль и страдания.
Ссылка на репозиторий: https://github.com/vityaman-edu/gradle-ktor-android-monorepo
продолжение в #42
Перед тем, как начать разрабатывать компоненты системы, хорошо бы создать для каждого из них свою папочку. Поскольку стек у нас очень похож, все можно собирать с помощью gradle. Также важно создать отдельный проект с логикой сборки, чтобы разделять скрипты для запуска линтеров, например. Предлагается такая структура.
Над названиями долго не думал, хорошо бы придумать нормальные, говорящие и не такие скучные.
В каждом подпроекте будет свой settings.gradle.kts, но все будут подтягивать build-logic в качестве зависимости, а там уже будут описаны всякие общие штуки.