2016-08-13 3 views
0

Я перехожу на Gradle как инструмент для создания Java-проекта. Мой главный проект (A) имеет зависимость от других проектов (B и C).Gradle Multiproject с SCM

В настоящее время каждый из этих проектов находятся в CVS индивидуально, и когда я хочу, чтобы скомпилировать ИИ должны проверить A, сделать подкаталог в вызываемом B, в котором я проверяю B. То же самое относится и к С.

Im собирается перейти к диспетчеру репозитория (nexus), в котором могут быть опубликованы B и C. Когда это произойдет, модуль А может просто иметь зависимость от B и C, которые он может получить от связи.

Однако трудности возникают, если я не хочу публиковать B и C (для целей тестирования), и я хочу построить A с моим последним кодом из B и C, не связывая его с nexus.

Мои первоначальные мысли об этом - построить банку для B и C и потянуть ее в папку «lib» для A. Однако я уверен, что есть лучший способ.

В maven я мог бы сделать «mvn clean install», который установил бы B и C в моем локальном кэше maven. Тогда он будет искать подходящие банки.

Но я все еще не уверен, что это лучший способ. Я посмотрел на подпроекты градиента, но я не полностью их понимаю. Как бы подмодули обрабатывались в SCM (мне также нужно было бы использовать git-подмодули?)

Я был бы признателен за некоторые рекомендации относительно наилучшей практики для этой ситуации. Благодаря

EDIT:

Ответ ниже от Вячеслава Швеца наиболее точный ответ, который я нашел до сих пор. Существует еще один способ отключить зависимость проекта от градиента с зависимостью в стиле maven.Это включает в себя замену зависимостей, как описано в https://docs.gradle.org/current/userguide/dependency_management.html#sec:project_to_module_substitution

Это может быть обернута вокруг:

if(project.hasProperty("someSwitch")){ 
    configurations.all{..... 
    .... 
    } 
} 

Использование этого метода было бы:

gradle build -Psomeswitch 

ответ

0

старый (классический) способ

Тот же подход, что и для Maven:

  1. Применить maven плагин на проекте B
  2. Запуск gradle clean install по проекту B

    На самом деле, вы не должны clean каждый раз, если ваша сборка правильно использует входы и выходы

  3. задачи В проекте A добавить mavenLocal() репозиторий и запустить сборку

Новый способ (experemental) - Композитные сборки

Составная сборка позволяет объединить несколько Gradle сборки и замены внешних зависимостей бинарных с зависимостями проекта, как если бы вы использовали один многостраничный проект строительство https://docs.gradle.org/2.13/release-notes

Это еще не доступно. Начиная с версии 2.13 вы можете использовать его с помощью API-интерфейса Tooling (например, плагин Buildship 2.0 для Eclipse IDE). Общее пользование будет доступно в версии 3.1, но вы можете попробовать его сейчас, используя nightly builds of 3.1

Если загрузить и выполнить demo build from Gradle's github с последней ночными сборками, вы увидите следующее:

$ gradle build 
[composite-build] Configuring build: C:\Users\Shvets\repos\composite\projectB 
[composite-build] Configuring build: C:\Users\Shvets\repos\composite\projectC 
:compileJava 
:projectB:b1:compileJava 
:projectB:b1:processResources UP-TO-DATE 
:projectB:b1:classes 
:projectB:b1:jar 
:projectB:b2:compileJava 
:projectC:compileJava 
:projectC:processResources UP-TO-DATE 
:projectC:classes 
:projectC:jar 
:projectB:b2:processResources UP-TO-DATE 
:projectB:b2:classes 
:projectB:b2:jar 
:processResources UP-TO-DATE 
:classes 
:jar 
:assemble 
:compileTestJava UP-TO-DATE 
:processTestResources UP-TO-DATE 
:testClasses UP-TO-DATE 
:test UP-TO-DATE 
:check UP-TO-DATE 
:build 

BUILD SUCCESSFUL 

Total time: 4.497 secs 

Для глубокого понимания см demo video of both approaches ,

Смежные вопросы