Gradle이 대세인 요즘 라이브러리 의존성을 땡겨받는 방법 중 크게 두 가지가 있다.
api(의존성 어쩌구 저쩌구)
implementation(의존성 어쩌구 저쩌구)
두 방식의 차이점은 의존성 연쇄에 대한 것에 있다.
api 구문
api 구문은 의존성이 연쇄되어 의존성이 끊어지지 않고 이어진다는 것이다. 예를 들자면 아래와 같다.
- A프로젝트 build.gradle에서
api(B프로젝트)
구문을 사용했다. - B프로젝트 build.gradle에서
api(C프로젝트) 혹은 implementation(C프로젝트)
구문을 사용했다.
이렇게 셋팅하면 A프로젝트에서 C프로젝트의 객체를 사용할 수 있다. A프로젝트가 직접 땡겨받고있는 B프로젝트가 C프로젝트를 땡겨받았고 이 의존성이 이어진 것이다.
implementation 구문
api 구문은 의존성이 연쇄되지 않는다. 위의 예시와 똑같은 상황에서 api
구문만 implementation
으로 바꾼 아래 상황을 예시로 한다.
- A프로젝트 build.gradle에서
implementation(B프로젝트)
구문을 사용했다. - B프로젝트 build.gradle에서
implementation(C프로젝트)
구문을 사용했다.
A프로젝트에서 C프로젝트의 객체를 사용하고자하면 컴파일 에러가 발생한다. A프로젝트는 B프로젝트만을 땡겨받겠다고 implementation
으로 선언했기때문이다.
api 구문을 사용하면 뭔가 나중에 쓸 기능에 대한 대비를 하여 확장성도 있어보이고 편리해보인다. 하지만 이 방식에는 단점이 있어 사용 시 권장되는 사항은 아니다.
api 구문을 사용하면 C프로젝트에서 변경이 일어날 때 A프로젝트도 새롭게 빌드해야한다.
당연하게도 의존성이 이어져있기 때문에 받고 있기 때문에 나는 C프로젝트만 변경했는데 총 3개의 프로젝트를 새롭게 빌드해야하는 상황이 온다.
빌드 시간이 증가할 뿐만 아니라 모듈 간 의존성이 강하게 엮여있기 때문에 관리에 복잡함이 추가될 수도 있다.
이러한 이유로 api구문을 최대한 지양하자는 내용이 많다.