Intellij Multi Module Project 구성하기 (with Gradle)

 

• root proejct 하나에, 그 하위로 sub module 여러 개를 두는 방식이 상호 import하기 좋다.
  • 여러개의 sub module로 나누어서 개발하는 프로젝트라면 하나의 repository를 쓰는 편이 좋은데, 어떤 기능이 어디서 사용되는지 파악하기 쉽기 때문이다. repo가 모듈 단위로 다 나뉘어져 있으면 기능 수정 할 때 이 기능이 어디서 참조되는지 찾아내기 쉽지 않다.
• 멀티 모듈로 만들기 전에 참고 - https://techblog.woowahan.com/2637/   
  • 여기 나온 사례의 문제점은 common의 의미를, "2개 이상 쓰는 곳이 있다면 common에 넣자"라고 생각해버려서, common이 너무 비대해졌다는 점.
  • common은 모듈 전역적으로 적용되거나 독립 모듈로 구성하기 애매한 것들만 넣고, (비즈로직이 아닌 것)
  • 나머지는 비즈니스 로직 별로 독립 모듈로 쪼개야 common이 비대해지는 것을 막을 수 있다.
  • plasma-benefit/posts/485  이 사례도 참고해볼만 하다.
  • https://share.navercorp.com/neday2022/lecture/1427158 이 사례도. core less 아키텍쳐의 장점과 그럼에도 코드 중복을 줄일 수 있는 방법에 대해 얘기하고 있다. (core가 아닌 supports)
  • 정리하면 공통 모듈이 아예 없는 것은 아니고, 비즈로직이 아닌, "지원", "유틸" 등에 속하는 것만 공통으로 뺄 수 있다.

 

멀티 모듈, 서브 모듈로 구성했을 때의 장점은?

• ▲ 관심 분리를 통한 스파게티 코드 방지, 변경 범위 축소
  • 왜 세모? 패키지만 나눠도 효과를 볼 수 있는 영역이기 때문.
  • 단, 분리된 패키지 간 참조는 양방향이고, 분리된 모듈 간 참조는 단방향만 가능하다는 중요한 차이점이 있다.
• O 독립된 모듈(library)로서 여기저기서 가져다 쓸 수 있는 확장성
• O 독립된 jar로 패키징하므로 별도의 main 가지고 단독 실행 가능
• O 모듈 별로 사용하는 의존성을 다르게 관리 할 수 있음 (게다가 버전도 다르게 갈 수 있다.)
  • 모듈이 나뉘어져있지 않고 패키지만 나뉘어진 구조에서 시스템이 비대해졌다면, 의존성 버전 하나 바꿀 때 테스트 해야 하는 범위가 너무 커질 수 있음. 
• X 단독 실행을 위해 패키징 하는 경우 jar 용량 감소 -> 어차피 용량이 커지는 주 요인은 라이브러리인데, 서브 모듈도 단독 실행을 위해 라이브러리를 포함해서 패키징 한다면 용량이 드라마틱하게 절감되지는 않는다.
• ▲ 구동 속도 향상 -> 기본적으로 jvm 환경에서는 초기 구동 속도가 빠른 편은 아니지만 서브 모듈이 framework 사용하지 않는다면  단독 실행 시 1s 이내 수준으로는 만들 수 있다.

 

root build.gradle 두는 방법

• https://daddyprogrammer.org/post/13156/spring-boot-change-multi-module/  
• https://velog.io/@haerong22/IntelliJ-%EB%A9%80%ED%8B%B0-%EB%AA%A8%EB%93%88-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%A7%8C%EB%93%A4%EA%B8%B0  
• https://velog.io/@mu1616/java-gradle-%EB%A9%80%ED%8B%B0%EB%AA%A8%EB%93%88-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

 

root build.gradle 없는 방법

• https://docs.gradle.org/current/userguide/multi_project_builds.html  
• https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html

이 방법은 공통으로 쓰이는 plugin 등이 중복해서 load 된다는 단점이 있다.
큰 문제는 아니지만 공통 설정을 명시할 root project나 common parent project를 두는 것이 나아보인다.

 

에러 정리

• plugin-request-for-plugin-already-on-the-classpath-must-not-include-a-version 에러 뜰 때  
• 패키지가 다르면 jar를 disable하면 못찾는다.
• sub module 구성하면서 Intellij의 Project Structure가 꼬인 경우(없는 모듈을 잡는다거나 중복해서 잡는다거나) settings.gradle에서 rootProject.name 변경해서 다시 잡아줄 것

 

Gradle implementation 과 compile(api)의 차이

• common 모듈에서, import 시 `` implementation 'coroutine'`` 으로 하게 되면
  • common 모듈을 가져다 쓰는 곳에서 어떻게 import하든, coroutine 모듈의 내용이 보이지 않는다.
• 반면 common 모듈에서 `` compile 'coroutine'`` 하게 되면
  • common 모듈을 가져다 쓰는 곳에서 coroutine 모듈의 내용이 보인다. (따라서 별도 임포트 필요 X. 충돌 가능성 올라감.)
  • `` compile``은 deprecated 되었고 `` api`` 로 바뀌었다.