그레이들(Gradle) 사용법
설정파일 build.gradle
-> 그루비, 코틀린: DSL 특화언어
DSL(Domain Specific Language)
ext{ //람다식
//코틀린, DSL 특화언어 사용 ...
}
1. 설치

그레이들 설치
releases page

압축 풀고 이름 폴더로 이동 ~

시스템 환경변수 PATH에 gradle bin폴더 경로 추가

2. 그레이들 명령어
1) 버전 확인
gradle --version

2) 프로젝트 생성
gradle init [--type 타입명]

enter + enter
자바 버전: 17
프로젝트 명: exam03
enter
groovy 2번으로
enter
enter


maven과 구조 동일

👩🏫참고) 메이븐
mvn archetype:generate
3) java-application 타입으로 생성 시 프로젝트 구조
4) 프로젝트 빌드
gradle build
- 프로젝트를 컴파일(빌드)한다.
- build.gradle에 apply plugin: 'java'가 추가된 경우 .jar파일로 패키징까지 된다.
- 컴파일된 파일들은 'app > build' 폴더 안에 생성되며, .jar파일은 'build > libs'에 패키징된다.
- 컴파일 - 테스트 - 배포
- 테스트가 실패하면 배포되지 않는다 !
gradle clean build

🌟배포 파일 생성 !!!

🔼gradle clean build 해줌, 빌드 실패! 배포가 되지 않았다.
👩🏫참고)메이븐
mvn package: compile test 배포
5) 프로젝트 실행
gradle run

build폴더 생성 ~.~
- 컴파일 후 메인클래스를 실행한다.
- 스프링부트의 경우 gradle bootRun을 통해 앱을 구동할 수 있다.
6) 프로젝트 패키징
7) 프로젝트 클린
gradle clean
- build 프로젝트 삭제
8) gradle-wrapper
- gradle 명령어로 프로젝트를 빌드할 수 있지만, gradle-wrapper의 실행명령으로도 task를 실행할 수 있다.
- 새로운 환경에서 gradle을 설치하지 않고도 빌드가 가능
- gradle 명령어의 경우 기본적으로 gradle이 로컬에 설치가 되어있어야 한다.)
- 또한 gradle 명령어로 빌드를 할 경우 로컬에 설치된 gradle 버젼으로 빌드되기 때문에, 개발 당시 버젼과 다를경우 문제를 일으킬 수도 있다.
- gradlew build를 사용하면 사용자가 프로젝트를 만든 사람과 동일한 버전으로 빌드를 할 수 있으며, 심지어 gradle이 설치되지 않아도 빌드가 가능하다.

📌명령어
gradle tasks: 그레들 내에서 작업할 수 있는 모든 명령어가 나옴
build.gradle
📚💻인텔리제이 내부에 gradle 편의기능이 탑제되어있다.
- 인텔리제이에서 gradle 프로젝트 생성

세팅

- buildscript
- gradle로 task 실행 시 사용되는 설정
- 어플리케이션 빌드와는 별개 설정(위 설정과 같이
repositories, dependencies를 따로 설정)
- ext
- 전역변수 블록
- 전역변수는
$전역변수명으로 사용할 수 있다.
def 변수명 = 값 <-- 지역변수
- classpath
- 라이브러리를 클래스 경로에 추가
- 빌드에서 실행까지 의존하는 라이브러리를 지정
- plugin
- 프로젝트에서 사용하는 Gradle 플러그인을 추가
(위에 설정된 플러그인들은 부트 환경에 필요한 플러그인)
- eclipse: eclipse IDE 에서도 Gradle Project를 개발할 수 있도록 플러그인이 설치된다.
- group : 프로젝트 생성시 groupId 설정
- version : 애플리케이션 버전 설정
- sourceCompatibility: 자바 버전 설정
- repositories
- 필요한 라이브러리를 다운로드할 저장소를 지정
- 공개저장소(jcenter)와, maven저장소를 사용할 수 있다.
- 상호보완 되도록 둘 다 사용하는 것을 권장
✨ 전역변수 사용

✨ 지역변수 사용

- dependencies : 라이브러리 추가
- compile, api
- 모듈 수정 시, 해당 모듈을 의존하고 있는 모듈을 모두 빌드, 빌드 속도가 느리다
- compile의 경우 Gradle 3.0부터는 사용을 권장하지 않는다(api로 대체)
- A(api) <- B <- C로 의존하는 형태라면 A 수정 시 B,C 모두 빌드
- implementation
모듈 수정 시, 직접 의존하는 모듈만 빌드, 빌드 속도가 비교적 빠르다.
A(implementation) <- B <- C로 의존하는 구조라면, A 수정 시 B만 빌드
- testImplementation : 테스트에 사용하는 라이브러리 추가
- annotationProcessor : 애노테이션 기반 라이브러리를 컴파일러가 인식하도록 함
예) lombok, queryDSL
- compileOnly : complie에만 필요하고, runtime에는 필요없는 라이브러리를 추가
- runtimeOnly : compile시에는 필요하지 않지만 runtime시에는 필요한 라이브러리 추가
- developmentOnly : 개발시에만 필요하고 compile시에는 제거 예) springboot devtools
🔸lombok gradle 의존성 설정

dependencies {
compileOnly group: 'org.projectlombok', name: 'lombok', version: '1.18.32'
testImplementation platform('org.junit:junit-bom:5.10.0')
testImplementation 'org.junit.jupiter:junit-jupiter'
}
#더 짧은 버전으로도 가능
dependencies {
compileOnly 'org.projectlombok:lombok:1.18.32'
testImplementation platform('org.junit:junit-bom:5.10.0')
testImplementation 'org.junit.jupiter:junit-jupiter'
}

이게 더 적합!
gradle은 테스트 환경에서 lombok 사용시 의존성 추가해줘야한다.


롬복 동작 확인 완료 !!
