멀티 모듈 생성 2

플러그인 버전이나 각종 변수들, 의존성 버전 같은 것들을 한 곳에 모아서 관리하는 방식을 알아보자. 

 

루트에 gradle.properties 파일 추가 

 

옆에 보고 작성

 

build.gradle.kts

이렇게 변수를 작성해서 매핑

 

 

플러그인 같은 경우에도 예를들어 코틀린 버전을 올리거나 스프링부트 버전을 올리거나 할 때, 버전 정보가 파편화되있으면 관리하기 까다로운 부분이 있는데, 그것을 gradle.properties에 모아서 사용한다. 

이것은 settings.gradle.kts에서 한다. 

 

settings.gradle.kts, 옆에 오타있음

 

이렇게 하면 build.gradle.kts 에 plugins에 버전을 지울 수 있다. 

 

이대로 demo-api 를 run 해보면 잘 실행이 되는 것을 볼 수 있다. 

이런 식으로 관리하면 스프링 버전을 올리거나 코틀린 버전이 올라갈 때 대응이 쉬워진다. 

 

 

demo-api에 application.yml 작성

 

 

 

이제 스프링 클라우드 의존성 버전들을 추가할 수 있게 하자.

gradle.properties

7번줄에 dependency-management 에 apply false 있었던거 지우고, 

저거 추가.

 

이제 로깅 모듈을 추가해보자 

sleuth 를 써보자. 

지금은 api 모듈이 하나니까 demo-api의 build.gradle.kts에서

implementation("org.springframework.boot:sleuth") 를 통해 설정을 해줄 수도 있는데, 

만약 API 모듈이 많거나 배치 모듈도 있거나 그러면 sleuth에 대한 의존성이 여러 모듈에 나눠져 있을것이다. 

따라서 로깅 모듈만 따로 구성을 해보자. 

 

마찬가지로 build.gradle.kts 를 만들고 sleuth 의존성을 추가해준다. 

이렇게 하면 sleuth 의존성을 검색하더라도 logging 모듈에만 나올 것이다. 

다음엔 logback 설정

sleuth나 다른 logging 관련된 것을 사용할 때 logging 쪽에 관한 property 들을 관리하기 위한 logging.yml

이렇게 하면 logging module의 기본적인 것는 된다. 

 

logging 모듈을 demo-api에 적용을 할 때는, 이렇게.

이렇게 하면, 만약에 API 모듈이 여러개일 때 sleuth라는 것을 직접적으로 쓰는 게 아니라 내부에서 한 번 더 격리해서 쓴다는 느낌이다.

 

추가로 logging.yml 관련해서 해줘야 할 것이, demo-api의 application.yml 에서 위 드래그한 부분 추가해 주기.

이렇게 하면 logging.yml에서 적용한 설정을 물고 demo-api로 들어온다고 생각하면 된다.