Gradle dependency 관련해서 검색을 하다보면,
어떤 글에서는 implementation을 사용하고 어떤 글에서는 compile을 사용하는 경우가 있다.
사실 어떻게 사용해도 돌아가긴 해서, 음... 무슨 차이지?하고 알아보기로 했다.
공식 문서에는 꽤 간단하게 설명되어 있지만, 정말 바로 알아들을 수 없..었..다...
(추가적으로 댓글에 정말 정말 좋은 내용을 남겨주셨다! api에 관해 더 궁금하신 분들은 해당 댓글을 확인해주시면 좋을 것 같다!!)
The dependencies required to compile the production source of the project which are part of the API exposed by the project. For example the project uses Guava and exposes public interfaces with Guava classes in their method signatures.
The dependencies required to compile the production source of the project which are not part of the API exposed by the project. For example the project uses Hibernate for its internal persistence layer implementation.
음.. 그래서 그림을 그려 보았다!
아래에 열심히 (본인이) 수작업한 그림을 보자.
A를 의존하고 있는 모듈이 B, C라고 가정하자. 또한 모듈의 구조는 Example of modules와 같다고 가정하자.
A라는 모듈을 수정하게 되면, 이 모듈을 직접 혹은 간접 의존하고 있는 B와 C는 모두 재빌드 되어야 한다.
A라는 모듈을 수정하게 되면, 이 모듈을 직접 의존하고 있는 B만 재빌드한다.
* 맥락에서 재빌드(rebuild)라는 표현을 썼지만 recompile이랑 동일한 표현으로 사용되었다.
그런데, Gradle 3.0부터는 Compile이 deprecated되었다고 한다.
(참고로 현재 버전이 4.8.1부터 6.2까지 documentation이 제공되고 있다!!!)
(아래 '중요 참고' 내용을 꼭 참고하시길!!)
1. 빠르다.
이건 사실 당연하다.
구조만 봐도 연결된 dependency가 확 줄어들고, change가 발생하더라도 recompile을 적게 하니 소요 시간도 적다.
2. API의 노출
API의 노출이 무슨 상관이지? 라고 생각할 수 있는데,
Design Pattern에서 흔히 강조하듯, Transparency는 중요하다.
User가 이상한 행동(?)을 하지 않게 필요한 API만 노출하는 것이 중요하고,
또한 User 입장에서도 간편하게 사용할 수 있기 때문에 잘 관리하는 것이 중요하다.(Facade 패턴이 그래서..!)
그런데, compile을 사용하게 되면 연결된 모든 모듈의 API가 exposed(노출)된다고 한다.
솔직히 반길 일은 아니라고 할 수 있다.
implementation을 사용하게 되면 이런 일이 없어진다.
compile 키워드가 deprecated되었다고 하더라도,
compile과 같은 방식으로 작동했으면 할 수 있지 않은가?
그래서 'api'라는 키워드를 사용하여 똑같이 사용할 수 있다!
(이와 관련된 내용은 아래 댓글에 더 세세하게 정리해주신 분이 있다! 👍)
compile | implementation |
testCompile | testImplmentation |
debugCompile | debugImplementation |
androidTestCompile | androidTestImplementation |
1. Gradle 공식 문서
2. StackOverFlow
@Transactional 파헤치기 (0) | 2022.02.15 |
---|---|
Jib란? (+ M1 Mac에서 빌드하기 & Kotlin DSL) (2) | 2021.09.06 |
댓글 영역