У меня есть несколько проектов Gradle (или рабочих пространств), которые частично зависят друг от друга. Например, у меня есть проект, предоставляющий
foo-api
, который будет использоваться другими проектами, такими как:
foo-impl
foo-provider
foo-client
В целях тестирования я поддерживаю локальный репозиторий Maven для компьютера. Во время разработки (если Вы можете назвать это так - я учусь) я публикую sh мои артефакты (maven-publish
) в моем локальном репозитории Maven , чтобы я мог импортировать их в нужных местах. Так как этот лог c очень специфичен c для меня, я хочу не использовать его в своем основном логе c.
До сих пор я придумал это решение (local
каталог существует в репозиториях шаблонов .gitignore
file )
// bnd-workspace-template-repo/settings.gradle.kts
...
if (file("local/local.settings.gradle.kts").exists) {
apply(from="local/local.settings.gradle.kts")
}
, а также:
// bnd-workspace-template-repo/build.gradle.kts
...
if (file("local/local.build.gradle.kts").exists) {
apply(from="local/local.build.gradle.kts")
}
И в моем производном проекте у меня есть что-то вроде этого:
Издательский проект
// foo-impl/local/local.build.gradle.kts
// will be applied to PROJECT_ROOT/build.gradle.kts
subprojects {
plugins.apply("maven-publish")
extensions.withType<PublishingExtension>()?.let {
publications {
// ...
}
repositories {
maven {
url = uri("/home/joe/developement/repositories/test-repo")
name = "test-repo"
}
}
}
}
В зависимости от проекта
// foo-consumer/local/local.build.gradle.kts
// will be applied to PROJECT_ROOT/build.gradle.kts
subprojects {
repositories {
maven {
url = uri("/home/doe/developement/repositories/test-repo")
name = "test-repo"
}
}
}
Это лучшее, что я придумал. Но я не знаю о жизненном цикле исполнения и настройки Gradle, и мне любопытно узнать о побочных эффектах.
Также я думаю об отмене этого подхода, и вместо этого для каждого проекта создайте неверсионный подпроект, делегированный для публикации. / локальное извлечение артефактов.
Но прежде чем я сделаю это, я хотел бы услышать некоторые решения (или лучшие лучшие практики ) относительно моей проблемы.
Тем временем я буду продолжить мой рабочий процесс таким образом.