Gradle 이란?

Gradle은 프로그래머가 작성한 코드를 파일로 변환해주고, 라이브러리/테스트/배포 등을 자동화하여 관리해주는 빌드 자동화 도구다.

빌드 도구를 사용하지 않으면 반복적인 작업을 수작업해야하고, 라이브러리를 직접 다운로드 및 버전 업데이트해야한다. 또 의존성 관리도 어렵다.

Gradle은 프로젝트의 구조를 보여준다. IDE에 프로젝트의 구조를 보여주기도한다. Gradle은 kotlin 버전으로도 제공해주고 Groovy 버전으로도 제공해준다.

Gradle의 특징

• 유연성
• 성능
  • build cache: 빌드 결과물을 캐싱하여 재사용. 라이브러리 의존성을 저장 후 캐싱.
  • 점진적 빌드: 마지막 빌드 호출 이후 변경된 부분만 빌드.
  • 데몬 프로세스 사용: 다음 빌드 작업을 위해 백그라운드에서 대기하는 프로세스
• 멀티프로젝트 빌드 지원
• configuration injection
  • 필요한 정보를 직접 프로젝트에 주입. 공통되는 정보는 묶어서 주입하고 프로젝트별로 설정을 다르게 주입 가능.

Gradle은 프로젝트의 구조를 보여준다. IDE에 프로젝트의 구조를 보여주기도한다. Gradle은 kotlin 버전으로도 제공해주고 Groovy 버전으로도 제공해준다.

강의에서는 코틀린 gradle을 보여주는데 intelliJ와 궁합이 잘맞기 때문이다.

실습

빈 프로젝트를 생성한다.

이 파일이 있으면 gradle 프로젝트인것을 인지한다. 확장자 kts는 코틀린을 의미하고 kts가 없으면 groovy가 된다.

gradle 관련 파일들이 생긴걸 볼 수 있다. wrapper가 있으니 gradle을 어딘가에 설치할 필요가 없다.

• gradlew / gradlew.bat: 실행 스크립트 windom/mac 용
• gradle-wrapper.jar: 실제 구현체
• gradle-wrapper.properties: 설정

강의에서는 7.4.2 버전을 쓴다. 코끼리 모양 reload는 인텔리제이가 프로젝트의 구조를 다시 읽게 하는거다.

그러고 나서 app, business-logic, data-model 디렉토리를 만들면 intelliJ가 파란색으로 별도 표시를 해준다. 각각이 컴포넌트라는걸 표시해준거다. 각각 컴포넌트가 어떻게 연결되는지는 나중에 해볼거다.

우리가 만드는 컴포넌트 말고도 프로젝트는 기존에 존재하는 외부 의존성도 가진다. 자바 라이브러리는 maven central에 존재한다. 따라서 Gradle에게 다른 컴포넌트들을 어떻게 찾을 수 있는지 알려줘야 한다. 만약 maven central 같은 호나경을 구축했다면 거기에 연결을 할 수도 있다. includeBuild()는 다른 gradle이 있다고 알려준다.

여기서 적은건 잠재적으로 어디서 찾을 수 있다고 알려준거기 때문에 실제로 프로젝트에 영향을 미치지 않는다. 다만 찾게 된다면 적은 곳에서 찾게 될 것이다.

gradle은 그 자체로 gradle plugins로 확장(extend) 가능하다. Jar와 Java code도 gradle 인터페이스를 구현했다. gradle 그 자체를 확장하는건 pluginManagement 키워드로 가능하다. includeBuild는 로컬에서 어디서 찾으면 될지이다.

rootProject.name은 필수는 아니다. 지정을 안하면 폴더명에서 가져온다. 그래서 만약 다른 사람이 다른 폴더에서 열면 이름이 바뀌기 때문에 고정 이름을 지어준다.

지금까지 app, business-logic, data-model 컴포넌트가 있다고 알려줬다. gradle에서 이 컴포넌트들의 이름은 subproject다. 또 나중에 필요한 것을 어디에 찾을지 알려줬다. 이건 mavenCentral일 수도 있고, 로컬에 있는 다른 gradle 빌드일 수도 있다.

실습2 - subproject들

위와 같이 자바 파일을 추가한다. 참고로 src-main-java는 gradle에서 자바의 표준 구조다. 아직 이 프로젝트에서 java 프로젝트를 인지할 방법이 없다. 그래서 단순히 폴더 구조로 보여진다.

이걸 자바 라이브러리 컴포넌트로 바꿔보자. subproject에서 의미를 주기 위해 build.gradle 파일을 작성하면 된다.

간결한 구조를 유지하려면 plugins {} 로 시작하면 된다.

이후 자바 파일을 인식하기 시작한다.

business-logic 에 같은 build.gradle.kts를 넣어주고, app에는 아래와 같이 넣어준다.

java app을 실행할 수 있게 해준다. 자바 라이브러리와 애플리케이션은 공통점이 많다 둘다 자바 프레임워크로 테스트도 가능하다.

java에는 핵심적인 기능들이 있고, java-library에는 거기에 좀 더한거다. 이럴때 java-library만 있으면 된다. 따라서 플러그인을 쓰는 것은 아주 강력한 기능이다.

여기서 java로 시작하는 블록은 'java' 플러그인의 확장이다. Gradle에서 DSL이 플러그인에서 확장되어 어떤 도메인을 더 명확히 하는 강력한 기능이다.

5. 공통화 하기

자바 버전을 일일이 지정하지 않아도 되는게, 자바 플러그인이 디폴트값을 가진다.

만약 자신만의 컨벤션을 지정하려면 위에 명시를 해야한다.

includeBuild의 주석을 해제해서 로컬에서 정의해서 쓰기로 한다. gradle 하위의 plugins 폴더도 추가로 찾아보게 될거다. 여기는 별도의 build이므로 별도 세팅 파일을 둘 수 있다.

별도의 빌드 파일이고 main 세팅 파일이 빌드되기 전에 먼저 되어야 하기 때문에 repositories.gradlePluginPortal()을 또 적어줬다.

kotlin-dsl 플러그인만 저런 방식으로 적으면 kotlin-dsl 플러그인을 가져온다.

business-logic, data-model에서 쓴다고 정의해놨던 my-java-library 플러그인을 만들었다.

이런식으로 추가적인 plugins 들을 정의 해놓으면 (gradle/plugins 처럼), convention 플러그인들을 여기에 두고 공유할 수 있다.

만약 코드 품질 관리를 위해 Spotless를 사용하고 싶다면 build.gradle.kts에 어디서 가져오면 되는지 알려줘야 한다.

의존성 추가

business-logic 컴포넌트에서는 data-model 의존성이 없기 때문에 아직 MessageModel을 사용할 수 없다.

implementation 키워드를 이용해 의존성을 추가할 수 있다. 로컬프로젝트이기 때문에 project 키워드로 추가했다.

application에 확장을 해서 main 클래스가 뭔지 지정해줬다.

빌드 실행하기

gradle에서 task는 빌드 프로세스의 기본 단위를 나타낸다.

task를 실행하면 그 전에 필요한 다른 task들을 실행하는 것들을 볼 수 있다. 빌드 된 것에 대해 캐시를 지정할 수도 있다.