그레들(Gradle) 사용법
1. 설치
gradle build tool
https://gradle.org/install/



ㄴ 압축해제, 이름파일로 옮김

ㄴ 깃 업로드 안되게끔 설정

ㄴ bin : 명령어들이 담긴 파일

ㄴ 경로 복사
ㄴ D:\박세현\gradle-8.7\bin
ㄴ 환경변수에 복붙용

ㄴ 환경변수 path
ㄴ 어떤 경로이든간에 접근가능하게 설정하는 것
ㄴ 어떤 경로이든 간에 명령어 쓸 수 있도록
2. 그레들 명령어
1) 그레들 명령어
gradle --version : 버전 확인
gradle tasks : 그레들 명령어 기억 안 날 때 확인용
예시) gradle --version

2) 프로젝트 생성
- gradle init [--type 타입명]
- 굳이 이렇게 생성안해도 됨 -> 그래들 설치안하고도 인텔리제이 통해서 그래들 프로젝트 생성 및 활용 가능
- 인텔리제이에 기능이 있음
- build.gradle : 프로젝트에 필요한 의존성과 빌드처리 내용을 작성하는 파일
- settings.gradle : 프로젝트에 대한 설정정보를 작성하는 파일
참고)
메이븐
mvn archetype:generate
그래들
gradle init [--type 타입명]
2-1) 그래들로 그래들프로젝트 생성

ㄴ 파일 경로이동

ㄴ 엔터 : 기본값 어플리케이션으로 한다는 말

ㄴ 엔터 : 기본값 자바로 한다는 말

ㄴ 자바 17버전으로 한다는 말

ㄴ 엔터
ㄴ 그루비 2번 엔터

다시다시...ㅜ

ㄴ 파일 생성하고 그래들 생성해야 함
ㄴ 이것 때문에 다시다시ㅠ


ㄴ 짠


ㄴ 래핑되어있는 그래들 명령어
ㄴ 다른 피씨에서 작업할 때 다른 그래들 버전일 수 있는데 그래들w 파일이 생성했을 시점의 그래들 버전그대로 명령어 넣어줌
ㄴ 다른 피씨에서 해도 ㅇㅋㅇㅋ하게 해준다

ㄴ gradlew run

ㄴ 사용할 수 있는 그래들 명령어

ㄴ sync : 의존성이나 빌드.그래들 파일 변경 있으면 업데이트(?)해주는 기능

ㄴ 설정파일
ㄴ 메이븐에서의 pom.xml이랑 동일

ㄴ 명령어 입력 터미널 : cmd

ㄴ 이렇게도 명령어 입력 가능

2-2) 인텔리제이로 그래들프로젝트 생성

ㄴ 앱이라는 폴더 없는거 빼고는 그래들 명령어로 그래들 프로젝트 생성한거랑 동일하게 만들어 짐



ㄴ 8.7 : 시스템에 설치된 그래들 버전
ㄴ 8.5 : 인텔리제이 내에 설치된 그래들 버전
-> 버전 불일치로 오류 뜨는 경우 많음
-> 인텔리제이 내에 설치된 그래들 버전으로 통일하자
3) 프로젝트 빌드
- gradle build
- gradle clean build : 그냥 build 보다 더 많이 씀
-> 배포할 수 있는 파일이 만들어 진다
- 프로젝트를 컴파일(빌드)한다.
- build.gradle에 apply plugin: 'java'가 추가된 경우 .jar파일로 패키징까지 된다.
- 컴파일된 파일들은 'app > build' 폴더 안에 생성되며, .jar파일은 'build > libs'에 패키징된다.
- 컴파일 -> 테스트 -> 배포
참고)
메이븐 mvn package : compile -> test -> 배포
그래들 gradle build : compile -> test -> 배포
예시)

ㄴ run했을 때보다 파일이 더 많넹

ㄴ 메이븐의 타깃파일과 동일한 파일
= 배포파일(jar파일)
예시) 테스트 실패 상황 연출

ㄴ 테스트 실패해서 배포파일 생성 실패
ㄴ 컴파일 -> 테스트(x) -> 배포(x)
-> 테스트 실패해도 배포 될수 있게 하는 법 없을 까
-> 테스트 과정 생략하고 배포하는 명령어 : gradle jar
5) 프로젝트 실행
- gradle run
- 컴파일 후 메인클래스를 실행한다.
- 스프링부트의 경우 gradle bootRun을 통해 앱을 구동할 수 있다.
예시) gradle run

ㄴ 컴파일 됨

ㄴ 메이븐은 타깃 폴더에 컴파일된 클래스파일들이 있음
ㄴ 그래들은 build 파일에 컴파일된 클래스파일들이 있음


ㄴ assemble : jar파일 생성
ㄴ build : 메이븐에서 패키지 생성과 동일한 개념
6) 프로젝트 패키징
- gradle jar
- 테스트x 배포하는 명령어
- 컴파일 -> 배포
- 프로그램을 .jar로 패키징
- 'build > libs'에 생성된다.
- apply plugin: 'java'가 추가된 경우 build명령으로 해결가능
참고) gradle bootjar : 스프링 부트에서...
예시)

ㄴ 테스트 과정없이 배포파일 생성
ㄴ 벗 테스트하고 배포하는게 더 안정감 있음...
7) 프로젝트 클린
- gradle clean
- build 디렉토리 삭제
- 기존 컴파일 된 파일을 지우는 명령어
예시) gradle clean

ㄴ build 폴더 삭제 됨
8) gradle-wrapper
- gradle' 명령어로 프로젝트를 빌드할 수 있지만, gradle-wrapper의 실행명령으로도 task를 실행할 수 있다.
- 새로운 환경에서 gradle을 설치하지 않고도 빌드가 가능
- gradle 명령어의 경우 기본적으로 gradle이 로컬에 설치가 되어있어야 한다.)
- 또한 gradle 명령어로 빌드를 할 경우 로컬에 설치된 gradle 버젼으로 빌드되기 때문에, 개발 당시 버젼과 다를경우 문제를 일으킬 수도 있다.
- gradlew build를 사용하면 사용자가 프로젝트를 만든 사람과 동일한 버전으로 빌드를 할 수 있으며, 심지어 gradle이 설치되지 않아도 빌드가 가능하다.
3. build.gradle
sourceCompatibity : 자바버전
ext {
// 전역변수
}
def 변수명 = 값 -> 지역변수
- buildscript
- gradle로 task 실행 시 사용되는 설정
- 어플리케이션 빌드와는 별개 설정(위 설정과 같이 repositories, dependencies를 따로 설정)
- ext
- 전역변수 블록
- 전역변수는 $전역변수명으로 사용할 수 있다.
- 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
참고) 메이븐
<dependency>
...
<scope></scope>
<dependency>
scope
- compile : 컴파일시에 포함, 배포시 포함
- runtime : 컴파일시에x, 실행 중 포함
- provided : 개발시에만 필요, 배포시에 배제
- test : 테스트시에 필요
예시)

ㄴ 메이븐의 compile과 비슷
ㄴ compile, api은 속도가 느려서 implementation을 더 많이 씀

ㄴ 메이븐의 provided와 비슷

ㄴ 메이븐의 runtime과 비슷
예시) 의존성 넣기_롬복



ㄴ 그루비
그룹 네임 버전 각각 명시
ㄴ 그루비 숏
compileOnly 'org.projectlombok:lombok:1.18.32' : 그룹 네임 버전 한번에 명시

ㄴ 메이븐의 prvided와 거의 동일한 기능

ㄴ 싱크
예시)

ㄴ 자바버전 : 17
ㄴ ext : 전역변수라서 어디든 접근 가능
ㄴ 변수 인식할려면 ""으로 바꿔줘야 함

ㄴ def : 지역변수
예시) test환경에선 롬복 쓰는 법


ㄴ 메이븐은 provided하면 main이든test든 롬복 애노테이션 다 되는데
ㄴ 그레이브는 이렇게 따로 각각 해줘야함

ㄴ 이제 테스트에서도 롬복 애노테이션 쓸 수 있군