build gradle multi-module project

[yeollow]

multi module project 구성

모든 의존성 관리는 rootProject 경로의 build.gradle에서 관리토록 한다.

• allprojects{ } : rootProject내부의 모든 모듈에 대한 필요 의존성을 등록
• subprojects{ } : rootProject 경로의 settings.gradle에 include되어있는 모듈들에 대한 필요 의존성을 등록
• project(':{module}'){ } : 각 모듈에서만 필요한 의존성을 등록
  • 각 모듈경로 내부의 build.gradle이 아님을 주의하자.

:batch

• spring-kafka client가 kafka broker의 topic에 data를 push (publisher)
• topic data를 fluentd가 hadoop에서 pull한 뒤 HDFS에 .txt파일으로 저장 (subscriber)
• HDFS의 .txt파일을 MR과정을 통해 GPS(longitude, latitude)를 뽑아내어 MariaDB에 저장 (SparkApplication) Spring Application과 Spark Application은 독립적인 Application이며 Jenkins Job을 통해 주기적으로 실행시켜줌.

:api

• front-end에서 request한 data를 실시간으로 DB에서 조회하여 반환
• front-end에서 전달하는 현재 GPS위치를 logging하여 file로 저장

:core

• 다른 module에서 공통적으로 사용하는 domain이나 entity등을 정의
  • core module의 경우 실행가능한 jar로 packaging하는 모든 모듈에 공통으로 들어가는 모듈로 main이 필요하지 않다.
  • 이렇게 단순 참조용 클래스만 있는 module을 위해 gradle에서는 기존에는 bootRepackage를 제공하였으나, 스프링 부트 2.0부터 bootJar와 bootWar로 Spring boot gradle plugin이 변경되었다.
    • 해당 프로젝트는 jar packaging을 목적으로 하며 bootJar를 비활성화 하기 위해 bootJar { enabled = false }, jar { enabled = true } 를 build.gradle의 project(':core'){}에 추가해준다. 공식 문서 참고

./gradlew :module-name:build 와 같은 명령어로 module별 jar packaging 가능. [gradle docs 참조] build이후 생성된 Jar파일은 module root의 build/libs에 생성됨

core module의 경우 모든 모듈이 공통적으로 내용을 담고 있기 때문에, 따로 jar를 패키징할 필요 없이 각 module의 jar파일 생성 시 자동으로 패키징된다.

[yeollow]

gradle version control

gradle build 시 gradle version문제로 update하라는 오류를 뱉을때에는 ./gradle wrapper -- gradle-version={gradle-version} 으로 gradle version을 바꿔주면 project의 /gradle/wrapper/gradle-wrapper.properties내의 distributionUrl 항목의 마지막에 바꾸고자 했던 gradle-version-bin.zip파일이 명시된다.

• gradlew 명령어 자체에서 오류를 뱉는다면, gradle-wrapper.jar를 project의 gradle/wrapper에 추가하도록 한다.
• gradle-wrapper.jar에 대해서는 .gitignore에서 무시하여 repo에 업로드 하도록 하였다.
• 해당 프로젝트에서는 gradle 6.8.1 version을 사용하고 있다. gradle version 정보

[yeollow]

해당 comment도 PR을 올려 issue와 link하는 식의 version control했어야 했는데.. main에 그냥 올리는 바람에 ㅎㅎ;; :-1: