의존성 범위

'자바' 플러그인은 자바를 위한 셋업을 해주고, jvm 언어들에 대해서도 해준다. 따라서 자바, 그루비, 스칼라, 코틀린 프로젝트는 '자바' 플러그인에 의해 셋업된다. configuration은 dependency들과 artifact들을 구성해주는 컨테이너의 일종이다. Configuration에는 크게 compile때 쓰일 것과 runtime에 쓰일 것들이 들어간다.

이건 다른 configuration들로 이뤄진 configuration이다. 따라서 여기서 implementation은 runtimeClasspath와 CompileClassPath에 포함되어있다.

로그 관련 코드를 추가했다.

app의 build.gradle 파일에서는 runtimeOnly로 추가한 것에 주목. 따라서 business-logic 컴포넌트를 다른 곳에서 쓴다면 runtimeOnly 디펜던시를 다른 logging implementation에 추가할 수 있다.

api는 business-logic에서 변경을 하면 app 프로젝트에서도 그게 보인다.

의존성 버전을 위한 중앙화 장소

불필요한 충돌들을 줄이려면 버전은 한 곳에서 중앙화해서 관리하는 것이 좋다.

dependencies.constraints는 의존성 제약 조건을 걸어준다. 이 키워드 자체로 의존성이 생기지 않고, 만약 common-lang을 쓴다면 3.12.0 버전을 써라 이 의미다. 이걸 중앙화 해보자.

include에 gradle/platform 추가.

java-platform은 의존성 제약 조건들과 의존성들만 묶어 놓은 파일이다. 이건 BOM (Bills of Materials)에서 아이디어를 받은거다. BOM은 POM, XML파일로 의존성 제약조건들을 포함한다.

이렇게 platform을 정의했으면 다른 곳에서 동일한 플랫폼을 쓰겠다고 선언해야 한다.

의존성 버전 카탈로그

platform 대신 파일로 관리할 수 있다. libs.versions.toml

충돌과 컴포넌트 메타데이터

프레임워크를 쓰면 그 자체로 의존성을 가지고 있고, 만약 라이브러리에 버전을 직접 버전을 설정했다면 충돌이 발생할 수 있다. 충돌이 나면 gradle은 가장 높은 버전을 쓴다.

./gradlew :app:dependencies --configuration runtimeClasspath