프로그래밍/java, spring

spring boot와 gradle

브래드 킴 2023. 2. 20. 16:25
728x90

gradle이란 빌드자동화도구이다.

 

여기서 말하는 빌드란, java를 컴파일한 후 필요한 라이브러리를 더해 실행가능한 jar, war등으로 패키징하는 일련의 과정을 말한다. gradle은 이를 편하게 자동화 시키는 도구라고 볼 수 있겠다. 개발자들은 빌드과정에 대한 고민필요 없이, intelliJ등 IDE를 통해 실행버튼 한번이면 gradle을 통해 빌드 후 실행까지를 편하게 할수가 있는 것이다.

 

spring initializer의 gradle 프로젝트 생성시 만들어지는 기본프로젝트를 기반으로 gradle관련 주요 파일들에 대해 하나씩 살펴보고자 한다.

groovy언어로 만들어진 build.gradle 등의 script를 생성하려면 groovy gradle을 만들고, kotlin으로 만들어진 스크립트를 사용하고자 한다면 kotlin gradle을 생성하면 된다. kotlin프로젝트를 사용중이라면 kotlin gradle을 만드는 것이 언어의 통일성 측면에서도 좋을 수 있겠다. 

 

group명은 최초 프로젝트 생성시 main/java 밑에 생성될 Package name을 의미한다. 위의 group명인 com.example에 Artifact명(aaa)까지를 더해 com/example/aaa 의 패키지를 만들어낸다.

 

Artifact는 전체 프로젝트 명을 결정한다. initializer에서 프로젝트를 생성하면 만들어지는 프로젝트명과 폴더명이 위의 Artifact의 aaa가 된다. 이때 결정된 프로젝트명은 settings.gradle의 rootProject.name에 세팅되게 된다. 추가적으로 폴더명과 프로젝트명이 달라지게 되면 폴더명[프로젝트명] 이런식으로 intellij상에 표시가 됨에 유의하자.

 

Name은 application의 이름을 결정한다. 위처럼 bbb라고 이름지으면 BbbApplication이라는 BbbApplication.java 파일이 생성된다.

 

이렇게 생성된 프로젝트는 아래와 같다. 이제 생성된 프로젝트의 구성파일을 하나씩 살펴보겠다.

gradlew, gradlew.bat

gradle-wrapper를 통해 build를 실행시키기 위한 실행스크립트이다. gradlew.bat파일은 윈도우용이고 gradlew은 범리눅스계열 파일로 보면 된다. 이 스크립트를 통해 실행가능한 jar, war파일을 만들어 낸다. 

./gradlew build

gradlew는 실행스크립트이므로 위와 같이 현재경로(./)까지 지정하여 실행하게 되면, build/libs 경로 안에 실행가능한 jar파일이 생성되게 된다. 이때에 plain이 붙어있는 jar도 생성이 되는데, 이는 클래스파일등의 리소스 파일만을 포함하는 소스코드 jar이다. 어플리케이션 실행을 위한 모든 의존성을 포함하지는 않는다.

 

gradle-wrapper.jar

gradle-wrapper파일은 gradle 빌드를 위한 파일들을 다운로드 받기 위한 code들이 들어있는 jar패키지이다.

 

gradle-wrapper.properties

gradle버전 및 gradle에 관련된 설정파일이다.

 

build.gradle

plugins {
	id 'java'
	id 'org.springframework.boot' version '3.0.2'
	id 'io.spring.dependency-management' version '1.1.0'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'

repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

tasks.named('test') {
	useJUnitPlatform()
}

 

plugins에서는 spring boot의 버전이 명시되어 있고, 버전을 변경하여 재 빌드 시킬수도 있다. 다만, sourceCompatibility에 명시된 java version과 호환되어야 함에 유의하자.

 

sourceCompatibility에는 자바소스코드를 컴파일할 자바버전이 명시되어 있다.

 

더불어, version에는 프로젝트 빌드 후 생성될 jar의 버전이 명시되어 있는데, 이는 앞서 설명한 ./gradlew build 를 통해 생성될 jar파일 명에 version에 명시된 버전이 이름으로 붙어 jar파일이 생성되게 된다.

 

repositories에서는 의존성 라이브러리를 다운받을 저장소 위치를 명시하게 된다. 일반적으로 mavenCentral()을 그대로 사용하겠지만,내부망에 구축되어 있는 nexus등의 라이브러리를 사용하게 될 경우 아래와 같이 변경하면 되겠다. 사실 내부망 repository를 사용하려면 credential등 추가적으로 설정해야 할것들이 있으므로, 검색해보시길 바란다.

maven { url "http://nexus.XXXXX.com:8081/nexus/content/groups/public/" }

 

dependencies에서는 필요한 의존성을 설정한다. 이곳이 개발자들이 가장 많은 수정을 가하는 곳이라 볼 수 있겠다. 

  • implemetation : 가장 일반적인 방식이고, 직접적으로 필요한 의존성만을 가져오는 설정이다. 이와 대비되는것은 api방식이다.
  • api(compile) : 일단, compile은 deprecated되었고 api로 대체되었다. api의 경우 implementation과 비교 했을때, 설정한 의존성 외에 상위모듈까지 모든 모듈의 의존성을 가져온다. 이는 보안성, 속도 등의 문제를 발생시키므로 되도록 사용하지 않는걸 추천한다.
  • testImplementation : 가져온 의존성라이브러리가 테스트 코드를 수행할 때만 적용된다.
  • compileOnly : 컴파일시에만 필요한 의존성을 사용하겠다는 것. 대표적으로 lombok을 선언할때 사용한다.
  • gradle5이후로는 annotationprocessor 추가. 
  • runtimeOnly : 런타임시에만 사용하겠다는 것이고, 대표적으로 DB관련 의존성과 로그의존성 등이 있겠다.

각각 영향도가 다른만큼, dependencies에 추가할때에는 검색을 통해 reference상 가장 일반적으로 사용하는 방법을 차용해서 사용하도록 하자.

728x90