Gradle 프로젝트 소스를 실행할 때, 로컬 컴퓨터에 프로젝트와 동일한 버전의 gradle 이 필요할 수 있는데 Wrapper 를 사용하면 해당 버전을 수동 설치할 필요가 없다. Gradle Wrapper 를 사용하면 지정된 버전의 gradle 이 없을 경우 자동으로 다운로드 및 설치를 하여, 해당 프로젝트를 동일한 gradle 버전으로 빌드할 수 있다. 구성원들의 안정적이고 표준화된 실행을 보장하기 위해 항상 Wrapper 로 빌드를 실행하는 것을 권장한다.

1. Wrapper 파일 생성

누군가 해당 소스를 받아서 Wrapper 를 사용할 수 있게 하려면, 미리 wrapper 파일을 생성해야 한다. 이 때는 gradle 이 로컬 컴퓨터에 설치되어 있어야 한다. 기본적으로 Gradle 프로젝트를 생성하는 init task 로 wrapper task 까지 실행된다. wrapper task 는 "Build Setup" 그룹에 존재하며, 이를 실행할 경우 프로젝트 디렉토리에 wrapper 파일을 생성해 준다.

$ gradle wrapper

gradle/wrapper/gradle-wrapper.jar
gradle/wrapper/gradle-wrapper.properties
gradlew(.bat)

• jar 파일은 properties 파일에 기반하여 Gradle 배포판을 다운로드하는 코드가 포함된다.
• gradlew 파일은 Wrapper 로 빌드를 실행하기 위한 스크립트이다.
• properties 파일에는 gradle 버전과 배포판 타입을 선택할 수 있으며 기본적으로 사용중인 gradle 버전을 따른다.

명령줄에서 직접 버전과 배포판 타입을 지정하여 wrapper 파일을 생성할 수도 있고,

$ gradle wrapper --gradle-version 7.2 --distribution-type all

이미 민들어진 properties 파일을 수정하여 동일한 결과를 만들 수도 있다.

distributionUrl=https\://services.gradle.org/distributions/gradle-7.2-all.zip

2. Wrapper 사용

$ gradlew build

※ IDEA 에서의 Gradle 설정

Wrapper 를 활용하는 가장 일반적인 방법은 프로젝트 생성하는 사람이 Wrapper 설정까지 마쳐놓고, 다른 개발자들이 IDEA 설정에서 wrapper 파일을 사용하도록 설정하는 것이다. 

간혹 수동으로 설치한 gradle 과 프로젝트 설정의 gradle 버전에 혼동을 느낄 수 있다. 로컬에서 프로젝트 gradle 버전 설정은 [File] - [Settings...] - [Build, Execution, Deployment] - [Build Tools] - [Gradle] 에서 설정한다. 그렇게 설정한 버전은 [View] - [Tool Windows] - [gradle] 창에서 사용된다.

하지만 [View] - [Tool Windows] - [Terminal] 에서의 gradle 은 수동 설치 후 로컬 컴퓨터의 환경 변수에 지정된 gradle 버전과 연결되어 있다. Terminal 에서 프로젝트 디렉토리 안에 있더라도 [Settings...] 에서 설정한 프로젝트의 gradle 버전과 연관이 없다. IDEA Terminal 이지만 CMD 와 같다.  [File] - [Settings...] - [Tools] - [Terminal] 에서 사용할 터미널 종류를 선택할 수 있다.

You can configure gradle wrapper to use distribution with sources. It will provide IDE with Gradle API/DSL documentation.

IDEA 에서 gradle-wrapper 사용시 배포판 타입이 바이너리 전용 파일을 사용하도록 설정되어 있는 경우 발생하는 알림이다. 수락하면 docs/source 를 포함한 all 버전의 gradle 로 설치되고 사용된다. (무시해도 상관없음)

Gradle 설치 파일의 배포판 타입(DistributionType).

1. gradle-version-bin.zip (bin: 바이너리만)
2. gradle-version-all.zip (all: docs, source 포함)

이 거지같은 한글 깨짐은 20년 동안 사라지질 않네.ㅋㅋ (한글 디스 아님!)

사건발단

1. 오늘 몇년전 프로젝트를 열었다가 IntelliJ 콘솔에서 우연히 한글깨짐을 발견했다.

2. 최근 프로젝트에서도 한글을 써보니 콘솔에서 한글깨짐이 발생했다. (한동안 영어만 쓰고 살았음...ㅡㅡv)

3. gradle 의 clean 작업을 실행하면서 build.gradle 의 한글이 깨졌으니 tomcat 의 문제는 아니다.

4. IntelliJ 가 실행될 때의 어느 곳에 있는 자바 옵션이 실행되는지를 체크하고 인코딩을 설정해야 한다. -Dfile.encoding=UTF-8

삽질

1. 시스템 환경변수 세팅

2. C:\Program Files\JetBrains\IntelliJ IDEA 2019.2.1\bin 의 idea.exe.vmoptions 과 idea64.exe.vmoptions

3. IntelliJ - Run/Debug Configurations - VM options

다 필요없음...

해결

IntelliJ - Help -  Edit Custom VM Options...  메뉴 열고  -Dfile.encoding=UTF-8  를 추가하여 해결.

파일위치는 C:\Users\username\.IntelliJIdea2019.2\config\idea64.exe.vmoption

오우... 사용자마다 세팅이 가능하게 되어 있나... 아니면 IntelliJ 사용자 등록하면서 별도 세팅이 되었던지...

암튼 이렇게 해결~~

devtools 는 이름처럼 어플리케이션 개발시 유용한 기능들을 포함하고 있는 Spring Boot 모듈이다.

개발 도중 결과를 확인하기 위해 build 를 수동으로 실행하고 브라우저를 새로고침 하여 결과를 확인하는 동작을 자동화하는 것이 특히 유용하다.

gradle 에서 devtools 를 사용하려면 dependency 에 아래처럼 한 줄만 추가한다.

그리고 IDE 마다 설정이 약간씩 틀린데 어플리케이션 실행 중 자동 빌드에 관련한 옵션을 설정한다. (아래: Intellij)

• File -> Settings [Ctrl-Alt-S] -> 검색 Compiler -> Build project automatically 체크
• [Ctrl-Shift-A] -> Registry... -> compiler.automake.allow.when.app.running 체크
• Run - Edit Configurations... - On 'Update' action / On frame deactivation: 적절히 선택 (Update classes and resources 등...)

이제 mainClass 를 실행(run) 시키고 코드를 수정하면 수초 뒤 변경 사항을 브라우저를 새로고침 하여 확인할 수 있다. 패키지(archive) 된 어플리케이션을 실행하면 production 모드로 간주하고 devtools 를 비활성화 하기 때문에 java -jar 나 bootRun 등을 이용하여 어플리케이션을 실행하면 devtools 는 동작하지 않는다. devtools 는 클래스 패스에 존재하는 코드 변경만 주시하므로, 특정 디렉토리의 코드만 자동 빌드가 되지 않는다면 클래스 패스에 추가하는 등의 방법으로 해결해야 한다.

Live Reload

spring-boot-devtools 모듈에는 리소스가 변경 될 때 브라우저가 새로 고침을 할 수 있게 하는 LiveReload 서버가 포함되어 기본으로 활성화 되어 있다.

서버브라우저에 liveReload 확장 프로그램을 설치하면, 코드 수정 후 사용자가 브라우저를 새로고침 하지 않아도 자동으로 새로고침 되어 보여진다.

Cache disabled

Spring Boot 의 몇가지 라이브러리는 성능 향상을 위해 캐시를 사용하는데, devtools 를 사용 중에는 사용자가 자동 빌드를 즉시 확인할 수 있도록, 알려진 템플릿 관련 캐시를 모두 비활성화 하는 것을 기본값으로 한다. application.properties 에 명시하여 수정도 가능하다. (예: spring.thymeleaf.cache=false)

아래는 devtools 의 자동화에 관련된 기본값이다. application.properties 파일에서 수정할 수 있다.

gradle 프로젝트에서 가져온 종족성의 크기가 어마무시하게 크다면...

Instagram 크롤링 때문에 instagram4j 라이브러리를 가져온 적이 있었는데 추가 종속성들의 크기가 200MB 가 넘었다. ㅡㅡ;;

필요한건 getUsers / getMedias 정도였는데 동영상 업로드 관련 기능들 때문에 각종 코덱 패키지들이 죄다 다운로드 되고 빌드됐다.

이럴 때 사용할 수 있는 것이 exclude 이다.

exclude group 한 줄 덕분에 관련 패키지들은 종속성에서 제외됐다. 

위 예제에 주석 처리한 것처럼 그룹이 아닌 특정 모듈만 제외할 수도 있다.

Spring Boot

Spring Boot 는 production 급의 독립형 Spring 어플리케이션을 쉽게 만들 수 있으며, spring 설정이 거의 필요없다.(고 하지만 이거슨 거짓말! ㅜ)

아래는 간략한 Spring Boot 의 특징이다.

• 독립 실행형 Spring 어플리케이션 생성.
• Tomcat, Jetty, Undertow 등의 WAS 포함. (WAR 파일 배포 불필요)
• 자동으로 Spring 설정.
• 상태 확인, 측정 및 외부 구성과 같은 production 기능을 제공.
• 코드를 생성하거나, XML 설정 파일이 불필요.

Spring Boot Gradle Plugin

Spring Boot 2.0 이상에서 gradle 로 시작하려 할 때, Spring Boot Gradle Plugin 을 사용하려면 Gradle 4.0 이상이 필요하며 다음과 같은 잇점이 있다.

• Spring-boot-dependencies 가 제공하는 종속성 관리 가능
• 실행 가능한 jar 또는 war 아카이브를 패키지화
• Spring Boot 어플리케이션 실행

1. Spring-boot-gradle-plugin 시작

Spring Boot Gradle Plugin 은 간단하게 plugins 블럭을 사용하여 프로젝트에 적용할 수 있다.

buildscript 블럭을 사용할 경우 다음과 같이 사용한다.

2. Spring-boot-dependencies 가 제공하는 종속성 관리

dependency-management 플러그인을 사용하면 특정 Spring boot 버전에 호환되는 종속성을 자동으로 가져오며 각 버전을 관리해 주기 때문에, 종속성 마다 버전을 기입할 필요가 없다. 아래처럼 최소한의 플러그인을 적용한다.

implementation 에는 종속성만 기입할 뿐 버전을 정의하지 않았다.

종속성의 다른 버전을 사용하고 싶은 경우 properties 를 지정하여 사용자 정의할 수 있으며, 호환성 문제를 꼭 체크하도록 한다.

3. 실행 가능한 jar 또는 war 아카이브 패키지화

Spring Boot Gradle Plugin 은 어플리케이션의 모든 종속성을 포함하는 실행 가능한 jar / war 파일을 생성하고 실행할 수 있다.

• 실행 가능한 jar : java 플러그인이 적용될 때 bootJar task 가 생성되며 이를 사용하여 jar 파일을 빌드할 수 있다. build task 를 실행하면 bootJar task 도 실행된다.
• 실행 가능한 war : war 플러그인이 적용될 때 bootWar task 가 생성되며 이를 사용하여 war 파일을 빌드할 수 있다. build task 를 실행하면 bootWar task 도 실행된다.

BootJar / BootWar task 는 Jar / War task 의 하위 클래스이다.

외부 컨테이너에서 java -jar 를 사용하여 war 파일을 실행하고 배포할 수 있도록 패키지화 하려면 서블릿 컨테이너 종속성을 providedRuntime 에 추가해야 한다.

기본적으로 bootJar / bootWar task 가 구성되면, jar / war task 는 비활성화 되는데 이를 활성화 시켜 실행 가능한 아카이브와 일반 아카이브를 동시에 빌드하도록 구성할 수 있다. 두 아카이브가 겹치지 않도록 둘 중 하나의 분류자(classfier) 를 구성할 수 있다.

실행 가능한 아카이브의 main 클래스는 task 의 classpath 에서 public static void main(String[]) 메소드를 가진 클래스를 찾아 자동으로 구성되는데 mainClassName 속성을 사용하여 명시적으로 구성할 수도 있다.

처음에 아카이브를 빌드하지 않고도 bootRun task 를 사용하여 어플리케이션을 실행할 수 있다.

또는 Spring Boot DSL 의 mainClassName 속성을 사용하여 프로젝트 전체에서 기본 클래스 이름을 구성할 수도 있다.

application 플러그인이 적용된 경우 mainClassName 프로젝트 속성을 사용하여 동일한 목적으로 사용할 수도 있다.

task 의 manifest 에 Start-Class 속성을 구성할 수 있다.

Spring Boot 프로젝트에 java plugin 이 함께 쓰이면, Spring boot plugin 은 다음과 같이 동작한다.

• bootJar task 생성. jar 파일은 main 소스셑의 런타임 클래스패스 상의 모든 소스를 포함하며, 클래스는 BOOT-INF/classes 에 패키징되고 jar 파일들은 BOOT-INF/lib 에 패키징 됨.
• jar task 비활성화.
• 어플리케이션을 실행하는 bootRun task 생성.
• bootJar task 에 의해 생성된 아티팩트를 포함하도록 bootArchives 를 생성.
• JavaCompile task 가 UTF-8 을 사용하도록 구성.
• JavaCompile task 가 파라미터(-parameters) 를 사용하도록 구성.

Spring Boot 프로젝트에 war plugin 이 함께 쓰이면, Spring boot plugin 은 다음과 같이 동작한다.

• bootWar task 생성. 표준 구성에 더하여 providedRuntime 구성이 WEB-INF/lib-provided 에 패키징 됨
• war task 비활성화.
• bootArchives 구성에 bootWar task 에 의해 생성된 아티팩트를 포함하도록 구성.

Spring Boot 프로젝트에 application plugin 이 함께 쓰이면, Spring boot plugin 은 다음과 같이 동작한다.

• main 속성 규칙으로 mainClassName 속성을 사용하도록 booRun task 구성.
• manifest 의 Start-Class 규칙으로 mainClassName 속성을 사용하도록 bootJar / bootWar task 구성.