다양한 크기와 모양의 build가 있지만, 공통의 특성이 있다.
- project의 root 혹은 master directory 안의 settings.gradle file
- root 혹은 master directory 안의 build.gradle file
- 스스로의 *.gradle 빌드 파일을 가지고 있는 Child directories (몇몇의 multi-project builds 는 child project build file을 생략할 수도 있다.)
settings.gradle 파일은 Gradle에게 project 와 subproject가 어떻게 구조화되어 있는지 말해준다. 운좋게도, 당신은 이 파일을 직접 읽을 필요가 없다.
간단히 gradle project 커맨드를 실행시킴으로써 프로젝트 구조에 대해 알 수 있다.
gradle -q projects 의 실행 결과
> gradle -q projects ------------------------------------------------------------ Root project ------------------------------------------------------------ Root project 'multiproject' +--- Project ':api' +--- Project ':services' | +--- Project ':services:shared' | \--- Project ':services:webservice' \--- Project ':shared' To see a list of the tasks of a project, run gradle:tasks For example, try running gradle :api:tasks
위를 보면 multiproject는 직접적인 3개의 child proejct(api, services, shared)를 가지고 있다는 것을 알 수 있다.
그리고, services 프로젝트는 자신의 child project인 shared, webservice를 가지고 있다.
각각의 프로젝트는 자신의 build 파일을 가지고 있지만 case에 따라 필수적인 것은 아니다. 위의 예를 보면, services 프로젝트는 단지 다른 subproject의 group 혹은 container이기 때문에,
service 프로젝트에 해당하는 build 파일이 존재하지 않는다. 하지만 multiproject 는 root project를 위한 build 파일을 가지고 있다.
root 프로젝트의 build.gradle은 종종 child 프로젝트에 공통적인 설정을 공유하기 위해 사용된다. 예를 들면 모든 child 프로젝트에 같은 set의 plugin과 dependency를 공유하는 것이다.
또한 모든 설정을 한 곳에 모으기 위해서, 각각 특정한 subproject를 설정하기 위해서도 사용할 수 있다. 이것은 당신은 특정한 subproject를 설정할 때, 항상 root build file을 체크해야한다는 것을 의미한다.
또 하나 생각해야 할 것은 build file은 build.gradle을 부르는 것은 아니라는 것이다. 많은 프로젝트가 subproject의 이름을 build file의 이름으로 사용한다. 예를 들면, api.gradle , services.gradle 같은 형식이다.
settings.gradle 파일을 통해서, 우리가 쓰는 IDE는 .gradle suffix를 찾아 build file로 간주한다.
Executing a multi-project build
user의 입장에서 보면, multi-project build는 실행시킨 task들의 모음과 같다. 다만 차이점은 어떤 프로젝트의 task를 실행시킬지 control하는 것이다.
이 것을 위해서 두가지 옵션이 있다.
- 당신이 실행시키길 원하는 subproject로 directory를 변경한 후, gradle
- Use a qualified task name from any directory, although this is usually done from the root. For example: gradle :services:webservice:build will build the webservice subproject and any subprojects it depends on.
- 한 디렉토리 부터의 적절한 이름으로 task를 실행시키기 (ex. gradle :services:webservice:build 는 webservice subproject와 관련된 dependency와 해당 project를 build할 것이다.)
첫번째 접근은 sigle-project 사용 예와 비슷하다. 하지만 Gradle은 multi-project build에서는 조금 다르게 동작한다. gradle test command는 현재 디렉토리와 관련된 어떠한 subproject 의 test task도 모두 실행시킬 것이다.
만약 root에서 실행한다면 api, shared, service:shared, services:webservice 의 task를 실행할 것이고, service project에서 실행한다면 services:shared와 services:webservice만 실행이 될 것이다.
두번째 접근은 특정한 이름을 사용해 실행시키는 것이다. 이것은 path와 비슷한데, '/'나 '\' 대신 ':' 로 시작한다는 것이 다르다. 그리고 path는 root project로부터 시작한다. 다르게 해석하면 가장 앞의 :는 root 프로젝트 자신을 나타낸다는 것이고,
다른 모든 콜론은 path separator로써 동작한다는 것이다.
그리고 명심해야할 것은 Gradle Wrapper를 사용한다면 첫번째 방법은 정상적으로 동작하지 않는다는 것이다. 왜냐하면 현재 당신이 root프로젝트에 있지않다면 wrapper script에 이것을 명시해주어야만 하기 때문이다.
예를 들면, 만약 당신이 webservice project에 있다면 당신은 ../../gradlew build 를 실행시켜야 한다.
원본 출처 : https://docs.gradle.org/current/userguide/intro_multi_project_builds.html
댓글 없음 :
댓글 쓰기