gradle 파일 이해하기

개요

• 지금까지 build.gradle 파일을 사용해서 java와 spring 파일들을 빌드했지만, 구조를 정확히 알지 못하는 느낌을 받았다. 그래서 gradle 파일이 어떤식으로 구성되는지 공부해 보려고 한다.

 

settings.gradle

rootProject.name = 'gradle-study'

• setting.gradle에는 루트 프로젝트의 이름이 설정되어 있다.
• setting.gradle에 서브 프로젝트를 추가하고, build.gradle에 각각에 맞는 스코프를 만들어 의존성을 주입하면 멀티 프로젝트를 구성할 수 있다.

 

SourceSet

• gradle을 이용해서 프로젝트를 생성하면 아래와 같이 SourceSet을 구성해 준다.
  • 그렇기 때문에 gradle로 프로젝트를 생성하지 않는다면 SourceSet의 구성이 달라진다.
• main은 실제 소스코드로 jar 파일로 만들어지는 코드가 위치한다.
• test는 테스트를 위한 소스코드가 위치하면 Junit으로 코드를 실행시킨다.
• 만약 resources에 포함된 *.java 파일을 제외하고 싶다면 아래와 같이 SourceSet을 설정해 주면된다.

sourceSets {
    main {
        resources {
            srcDir "${project.projectDir}/src/main/java"
            // exclude "**/*.java" : 하지 말것. Gradle에서 문제 없지만 Eclipse에서 문제를 일으킴.
        }
    }
}

 

plugins

plugins {
    id 'org.springframework.boot' version '2.4.8'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id "com.ewerk.gradle.plugins.querydsl" version "1.0.10"
    id 'java'
}

• 플러그인 블록은 재사용 가능한 빌드 로직을 패키지화하여 task로 제공해 빌드시 사용할 수 있도록 도와준다.
• 만약 build.gradle파일 안에 있는 코드를 전부 주석처리하면 아래와 같이 help, build setup, other 만 남는다.

• help : 프로젝트에 대한 정보들을 알려주는 역할을 한다.
  • dependencies를 수행하면 프로젝트의 디펜던시에 대한 정보를 확인할 수 있다.
• bulid setup: 그래들 프로젝트를 셋업하는 역할을 한다.
  • init을 수행시키면 build.gradle이 생성한다.
  • wapper을 실행하면 gradlew와 gradlew.bat이 생성한다.
• 다시 주석을 풀고 빌드하면 아래와 같이 많은 task 들이 생긴다.

• 그 다음 build 라는 task 밑에 build를 실행해 보면 아래와 같이 task 들이 실행되는것을 확인할 수 있다.

 

option

group = 'com.hyunwook'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

• group: 아티팩트의 그룹명이다.
• version: release될 버전이다. 빌드시 jar파일 뒤에 version 정보가 붙어서 생성된다.
• sourceCompatibility: java 소스를 컴파일 할 때 사용되는 java 버전이다.

 

repositories

repositories {
    // 메이븐 저장소
    mavenCentral()

    // 사설 저장소
    maven {
    }
    ivy {
    }
}

• repositories 블록은 프로젝트 빌드에 필요한 의존성를 다운받을 저장소이다.
• mavenCentral은 maven의 중앙저장소로 gradle 내장 함수 mavenCentral()를 이용해 중앙저장소에 있는 의존성들을 가져올 수 있다.
• gradle은 중앙 저장소 뿐 아니라 maven,ivy로 구축된 사설 저장소에서도 의존성을 가져올 수 있도록 지원한다.
• maven저장소를 구축해서 의존성 파일들을 넣어놓고 위와 같이 설정한다면 자신의 repo 에서 의존성을 가져올 수 있다.
  • 사내에서 많이 구축하여 사용한다.
  • 구글에 자신만의 maven repository를 구축하면 된다.

 

dependencies

• dependencies 블록은 프로젝트에 필요한 의조성들이 표시된다.
• 이행적 의존성 관리란 추가한 의존성이 의존하고 있는 의존성들이 같이 넘어와 관리되는 것을 말한다.

 

Dependency Configuration

• 분홍색: 구성 요소가 라이브러리를 컴파일하거나 실행할 때 사용된다.
  • apiElements
    • 라이브러리를 컴파일(Complie)한다.
    • 해당 라이브러리를 컴파일하는 데 필요한 모든 요소를 검색할 때 사용한다.
    • implemenation이나 runtime 의존성에 대한 정보를 노출하지 않는다.
  • runtimeElements
    • 라이브러리 실행(Runtime)한다.
    • 해당 라이브러리를 실행하는 데 필요한 모든 요소를 검색할 때 사용한다.
• 파란색: 구성 요소 자체 사용을 위해 구성 요소 내부에서 사용된다.
  • complieClassPath: 소스를 컴파일할 때 사용할 classPath를 말한다.
  • runtileClassPath: 소스를 실행시 사용할 classPath를 말한다.
• 초록색: 사용자가 의존성을 선언할 때 사용된다. 또한 라이브러리마다 필요한 시점이 다르기 때문에 거기에 맞게 사용해야 한다.
  • api
    • 컴파일 타임에 필요한 라이브러리를 말한다.
    • 의존 라이브러리가 수정되는 경우 본 모듈을 의존하는 모든 모듈들을 재빌드한다.
    • A <- B <- C 의 구조에서 C에서는 A 접근이 가능하며 A가 수정되면 B, C가 재빌드 된다.
  • implementation
    • 내부적으로만 사용되고 사용자에게는 의존성을 노출시키지 않게 선언한다.
    • 런타임 시점에 노출되며, 의존 라이브러리를 수정해도 본 모듈까지만 재빌드한다.
    • A <- B <- C 의 구조에서 C에서는 A에 접근할 수 없고, A 수정 시 B까지만 재빌드한다.
  • compileOnly
    • 컴파일 시점에 꼭 필요한 라이브러리를 말한다.
    • 대표적인 예로는 Lombok이 있다.
    • 컴파일 시에만 빌드하고 빌드 결과물에는 포함하지 않는다.
  • runtimeOnly
    • 컴파일 시점에는 필요 없지만 런타임 시점에 필요한 라이브러리를 말한다.
    • 대표적인 예로는 Logging 관련 라이브러리와 DB 관련 라이브러리 등이 있다.
  • annotationProcessor
    • annotation processor를 명시하기 위해 사용한다.

 

프로젝트 의존성 관리

dependencies {
    compile project(':sub') 
}

• 프로젝트 의존성을 사용하면 해당 프로젝트에서 다른 프로젝트의 의존성을 가져올 수

 

파일 의존성 관리

dependencies {
    runtime files('common.jar', 'system.jar')
}

• 일반 jar파일의 경로를 적어주어 의존성을 추가할 수 있다.
• 이렇게 하면 maven 중앙저장소나, 사설저장소에 넣지 않고도 의존성 추가가 가능하다.

REFERENCES

• https://kwonnam.pe.kr/wiki/gradle/java
• https://javabom.tistory.com/36
• https://twinparadox.tistory.com/630