
빌드 자동화 도구에는 대표적으로 Maven,Gradle,Yarn,Npm 등이 있다.
프로젝트에 필요한 의존성들의 관리와 패키징 작업을 대신해주기 때문에, 개발자는 개발에만 집중할 수 있다.
그루비(Groovy)기반의 빌드 자동화 도구
명령어를 통해 Gradle 프로젝트 생성해보기
Gradle 설치가 끝났다면, 아래 명령어로 버젼을 확인할 수 있다.
$ gradle --version
$ gradle init [--type 타입명]
프로젝트에 필요한 초기 환경을 구성한다.
타입을 주지 않는 경우 아래의 절차대로 진행하며, 타입을 줄 경우 'build script DSL' 절차부터 진행된다. 예: 'gradle init --type java-application'
반드시 프로젝트 디렉토리를 만들어, 그 안에서 작업할 것!
Select type of project to generate:
1: basic
2: application
3: library
4: Gradle plugin
Enter selection (default: basic) [1..4]
Select implementation language:
1: C++
2: Groovy
3: Java
4: Kotlin
5: Scala
6: Swift
Enter selection (default: Java) [1..6]
Split functionality across multiple subprojects?:
1: no - only one application project
2: yes - application and library projects
Enter selection (default: no - only one application project) [1..2] 1
Select build script DSL:
1: Groovy
2: Kotlin
Enter selection (default: Groovy) [1..2]
Select test framework:
1: JUnit 4
2: TestNG
3: Spock
4: JUnit Jupiter
Enter selection (default: JUnit 4) [1..4]
basic 타입으로 생성 시 프로젝트 구조
Gradle 프로젝트의 필수환경만 제공하며, 로우레벨에서 프로젝트를 구성해야 한다.
.
├── build.gradle
├── .gradle
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
java-application 타입으로 생성 시 프로젝트 구조
Gradle 프로젝트 환경 + 자바 어플리케이션 환경이 구성되며, mainClass는 'App.java'로 설정된다. ("hello world!" 출력)
.
├── .gradle
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
└── app
├── build.gradle
└── src
├── main
│ └── resources
│ └── java
│ └── App.java
└── test
└── resources
└── java
└── AppTest.java
gradle에서 task는 프로젝트의 작업단위다.
gradle이 제공하는 task들이 있고, build.gradle에서 사용자가 직접 만들 수도 있다.
gradle이 제공하는 task의 경우 아래 명령어를 통해 확인 가능하다.
(프로젝트 타입에 따라 제공되는 task가 다르다.)
$ gradle tasks

프로젝트 빌드
$ gradle build
apply plugin: 'java'가 추가된 경우 .jar파일로 패키징까지 된다.
프로젝트 실행
$ gradle run
$ gradle bootRun을 통해 앱을 구동할 수 있다.프로젝트 패키징
$ gradle jar
apply plugin: 'java'가 추가된 경우 build명령으로 해결가능프로젝트 클린
$ gradle clean
위와 같이 'gradle' 명령어로 프로젝트를 빌드할 수 있지만, gradle-wrapper의 실행명령으로도 task를 실행할 수 있다.
굳이 gradle 대신 wrapper를 사용하는 이유는 뭘까?
새로운 환경에서 gradle을 설치하지 않고도 빌드가 가능하다.
gradle 명령어의 경우 기본적으로 gradle이 로컬에 설치가 되어있어야 한다.
또한 gradle 명령어로 빌드를 할 경우 로컬에 설치된 gradle 버젼으로 빌드되기 때문에, 개발 당시 버젼과 다를경우 문제를 일으킬 수도 있다.
./gradlew build를 사용하면 사용자가 프로젝트를 만든 사람과 동일한 버전으로 빌드를 할 수 있으며, 심지어 gradle이 설치되지 않아도 빌드가 가능하다.
리눅스
$ ./gradlew [Task명]
윈도우
> gradlew [task명]
기본 스프링부트 환경 build.gradle 알아보기
아래는 스프링부트 웹 어플리케이션의 기본환경이다.
buildscript {
ext {
springBootVersion = '2.3.7.RELEASE'
lombokVersion = '1.18.10'
}
repositories {
mavenCentral()
jcenter()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
group 'gradle.test.javaapp'
version '1.0-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
jcenter()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web'
// api '...'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
compileOnly "org.projectlombok:lombok:$lombokVersion"
// runtimeOnly '...'
annotationProcessor "org.projectlombok:lombok:$lombokVersion"
}
repositories, dependencies를 따로 구현해야함.)$전역변수명으로 사용할 수 있다.compile의 경우 Gradle 3.0부터는 사용안하는 것을 권장(api로 대체)A(api) <- B <- C 로 의존하는 구조라면, A 수정 시 B,C 모두 빌드A(implementation) <- B <- C 로 의존하는 구조라면, A 수정 시 B 만 빌드ex.) lombok, queryDSL 등이처럼 build.gradle을 작성해서, 본인이 원하는 환경의 어플리케이션 환경을 구축할 수 있다.
위의 예제는 기본적인 구성으로, 여기서 직접 task 또는 빌드-잡을 구현하여 얼마든지 응용할 수 있다.