엄범

 

• gradlew가 무엇인가?
• Gradle Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary.

 

Gradle이 maven보다 좋나?

• https://docs.gradle.org/current/userguide/build_cache.html  
  
  • gradle은 빌드 정보 등을 캐싱 해두고 사용하기 때문에 성능 이점이 있음
• gradle daemon을 띄워 두고, 여기서 Task를 수행하기 때문에 프로세스 띄우는 시간을 절약할 수 있음
  
  • 별도 설정 없는 경우 daemon은 2시간 동안 작업이 없으면 죽음

 

jar 배포 및 실행

1. Running `` gradle build`` from terminal, 
2. switching to /build/libs and then running 
3. `` java -jar artifactname`` works just fine.

 

gradlew 명령어 종류 (build VS bootJar)

• gradlew 명령어 종류와 설명  
• `` --dry-run`` 옵션을 주면 어떤 Task를 실행하는지 확인 가능

 

```

> Task :compileKotlin
> Task :compileJava NO-SOURCE
> Task :processResources
> Task :classes
> Task :bootJar

------ 여기까지가 bootJar 실행했을 때 ------
> Task :inspectClassesForKotlinIC
> Task :jar SKIPPED
> Task :assemble
> Task :compileTestKotlin
> Task :compileTestJava NO-SOURCE
> Task :processTestResources NO-SOURCE
> Task :testClasses UP-TO-DATE

> Task :test

> Task :check
> Task :build

------ 여기까지가 build 실행했을 때 ------

```

 

깃에 올려놓은 gradlew가 실행 권한이 없다고 permission error가 뜰 때

```bash

git update-index --chmod=+x gradlew

```

 

IntelliJ에서 사용할 때

• https://www.jetbrains.com/help/idea/gradle.html
• The recommended way to execute any Gradle build is with the help of the Gradle Wrapper.
  • Gradle Wrapper를 쓰는게 기본 설정으로 되어 있고, 프로젝트 마다 독립적인 Gradle을 자동으로 내려받고 실행하기 때문에 Gradle version으로 인한 문제를 피할 수 있음.
  • 어떤 버전을 내려받을지는 `` gradle-wrapper.properties ``에 명시.

 

자주 뜨는 에러

```

Could not determine Java version using executable

```

gradle 버전에 따라서 java -version 파싱에 문제가 있어 이런 에러가 뜰 수도 있는데, gradle-wrapper.properties에 명시된 gradle버전을 바꿔주어 새로운 버전을 내려받아 사용하도록 하면 해결됨. 

 

 

```

$ ./gradlew

오류: 기본 클래스 org.gradle.wrapper.GradleWrapperMain을(를) 찾거나 로드할 수 없습니다.

```

IntelliJ에서 빌드하면 default gradle wrapper를 사용하도록 설정해놓은 경우 아무 문제없이 실행이 되는데, 콘솔에서 직접 접근해서 실행하면 저런 오류가 발생한다. 이는 gradle-wrapper.jar가 없어서 발생하는 오류임.

 

이렇게 오류뜨면 로컬에 gradle 설치하고 gradle wrap 치면 ./gradle/wrapper/gradle-wrapper.jar 가 생성되면서 해결이 되기는 하는데... 문제는 로컬 gradle 버전에 맞게 gradle-wrapper.properties 파일이 수정돼버려서, 여러 프로젝트에서 각각 다른 gradle 버전을 사용하는 경우 커밋할 때 몹시 거슬린다...

 

IntelliJ가 default gradle wrapper라고 깔아놓은 gradle은 다음 경로에 있다.

```bash

$GRADLE_USER_HOME/wrapper/dists/gradle-<version>...

환경변수가 정의되어 있지 않은 경우 ~/.gradle임.

```

이를 사용할 수 있지만 그래도 gradlew에 뭔가 주석이 더 추가된다.

 

그냥 로컬에서 쓰는거 따로, IntelliJ에서 만든 프로젝트는 IntelliJ에서 빌드하는걸로...

 

설치하기 ~.~

• https://linuxize.com/post/how-to-install-gradle-on-centos-7/

 

bootJar와 Jar의 차이

• 기본적으로 SpringBoot에서 Build를 실행하면 다음과 같이 bootJar 태스크는 실행하고 jar 태스크는 스킵해서, BootJar를 만들도록 되어 있다.

```

> Task :bootJar
> Task :jar SKIPPED

```

• 이 스킵은 단독으로 Jar 태스크를 실행 했을 때도 마찬가지인데, build.gradle.kts에 다음과 같이 추가하면 Jar를 스킵하지 않을 수 있다.

```kt

tasks.getByName<Jar>("jar") {
    enabled = true
}

```

• 이렇게 하고 java -jar로 실행해보면, bootJar 태스크로 만든 .jar는 부트 앱이 잘 뜨는 반면, 그냥 Jar 태스크로 만든 .jar는 "기본 Manifest 속성이 없습니다." 라고 뜬다.

 

Dependency 를 Exclude 했는데 제대로 되지 않을 때?

```kt

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-webflux") {
        exclude(group = "org.springframework.boot", module = "spring-boot-starter-logging")
    }

    ...

}

```

• 이렇게 명시했으나 제대로 exclude가 되지 않을 수 있는데, 이는 타 모듈에서도 spring-boot-starter-logging에 대한 의존성을 가지고 있어 그렇다. (다른애들 다 주석처리 하고 해보면 됨.)
• 그래서 뭔가를 exclude할거면, 이렇게 하는 방법 보다는 configurations를 사용하는 방법이 좋다.
  
  • dependency_management.html#excluding_a_dependency_from_a_configuration_completely