아티펙트(Artifact)
기능(Capability)
컴포넌트(Component)
구성(Configuration)
의존성(Dependency)
의존성 제약(Dependency constraint)
기능 변형(Feature Variant)
모듈(Module)
모듈 메타데이터(Module metadata)
컴포넌트 메데이터 규칙(Component metadata rule)
모듈 버전(Module version)
플랫폼(Platform)
게시(Publication)
리포지터리(Repository)
분석 규칙(Resolution rule)
전이적 의존성(Transitive dependency)
(컴포넌트의)변형(Variant (of a component))
변형 애트리뷰트(Variant Attribute)

의존성 관리 용어(Dependency Management Terminology)

의존성 관리에는 다양한 용어가 함께 제공된다. 여기서 사용자 가이드 레퍼런스와 일반적으로 사용되는 용어를 찾아볼수 있다.

아티펙트(Artifact)

JAR, ZIP 배포, 또는 실행 파일 같이 빌드로 생성된 파일 또는 디렉토리다.

아티팩트는 일반적으로 사용자 또는 다른 프로젝트에서 사용 또는 소비되거나 호스팅 시스템에 배포되도록 설계됐다. 이러한 경우 아티팩트는 단일 파일이다. 게시 가능한 아티팩트를 생성하는 비용을 피하기 위해 프로젝트 간 의존성이 있는 경우 디렉토리가 일반적이다.

기능(Capability)

기능(feature)은 하나 또는 여러 컴포넌트가 제공하는 기능(capability)을 식별한다. 기능(Capability)은 모듈 버전에 사용되는 좌표(coordinate)와 유사하게 식별된다. 기본적으로 각 모듈 버전은 해당 좌표와 일치하는 기능을 제공한다(예: com.google:guava:18.0). 기능은 컴포넌트가 여러 기능 변형을 제공하거나 서로 다른 두 컴포넌트가 동일한 기능을 구현한다는 것(따라서 함께 사용할 수 없음)을 표현하는 데 사용될 수 있다. 자세한 내용은 기능(Capability) 장을 참고하자.

컴포넌트(Component)

모듈의 단일 버전이다.

외부 라이브러리의 경우, 컴포넌트라는 용어는 게시된 라이브러리 버전 중 하나를 나타낸다.

빌드에서 컴포넌트는 플러그인(예: 자바 라이브러리 플러그인)에 의해 정의되며 게시하는 간단한 방법을 제공한다. 이는 아티팩트뿐 아니라 컴포넌트의 변형을 자세히 설명하는 적절한 메타데이터로 구성된다. 예를 들어 기본 설정의 자바 컴포넌트는 jar 태스크에 의해 생성된 JAR과 자바 API 및 런타임 변형의 의존성 정보로 구성된다. 또한 해당 아티팩트를 사용하여 소스 및 자바독(Javadoc)과 같은 추가 변형을 정의할 수도 있다.

구성(Configuration)

구성은 특정 목표를 위해 함께 그룹화된 명명된 의존성 집합이다. 구성은 기본, 확인된 모듈 및 해당 아티팩트에 대한 접근을 제공한다. 자세한 내용은 의존성 구성과 분석 및 소비 구성에 대한 절을 참고하자.

“구성(configuration)”이라는 단어는 오버로드된 용어이며 의존성 관리의 맥락 밖에서는 다른 의미를 갖는다.

의존성(Dependency)

의존성은 모듈을 빌드, 테스트 또는 실행하는 데 필요한 다른 소프트웨어 부분에 대한 포인터다. 자세한 내용 의존성 선언 장을 참고하자.

의존성 제약(Dependency constraint)

의존성 제약 조건은 의존성에 대한 유효한 분석(resolution) 결과를 만들기 위해 모듈이 충족해야 하는 요구 사항을 정의한다. 예를 들어 의존성 제약 조건은 지원되는 모듈 버전 집합의 범위를 좁힐 수 있다. 의존성 제약 조건은 전이적 의존성에 대한 이러한 요구 사항을 표현하는 데 사용될 수 있다. 자세한 내용은 전이적 종속성 업그레이드 및 다운그레이드에 대한 절을 참고하자.

기능 변형(Feature Variant)

기능 변형은 개별적으로 선택하거나 선택하지 않을 수 있는 컴포넌트의 기능을 나타내는 변형이다. 기능 변형은 하나 이상의 기능(capabilities)으로 식별된다. 자세한 내용은, 기능 변형 및 선택적 의존성 모델링 절을 참고하자.

모듈(Module)

예를들어, 구글 구아바(Guava)는 시간이 지남에 따라 발전하는 소프트웨어다 모든 모듈에는 명칭이 있다. 모듈의 각 릴리스는 모듈 버전으로 표시된다. 편리한 사용을 위해 모듈을 리포지터리에서 호스팅할 수 있다.

모듈 메타데이터(Module metadata)

모듈 릴리스는 메타데이터를 제공한다. 메타데이터는 모듈을 더 자세히 설명하는 데이터다. 아티팩트의 위치 또는 필요한 전이적 의존성에 대한 정보. 그레이들은 그레이들 모듈 메타데이터(.module 파일)라는 자체 메타데이터 형식을 제공하지만 메이븐(.pom) 및 아이비(ivy.xml) 메타데이터도 지원한다. 지원되는 메타데이터 형식에 대한 자세한 내용은 그레이들 모듈 메타데이터 이해 절을 참고하자.

컴포넌트 메타데이터 규칙(Component metadata rule)

컴포넌트 메타데이터 규칙은 누락된 정보를 추가하거나 잘못된 정보를 수정하기 위해 리포지터리에서 컴포넌트를 가져온 후 메타데이터를 수정하는 규칙이다. 분석(resolution) 규칙과 달리 컴포넌트 메타데이터 규칙은 분석이 시작되기 전에 적용된다. 컴포넌트 메타데이터 규칙은 빌드 로직의 일부로 정의되며 플러그인을 통해 공유될 수 있다. 자세한 내용은 컴포넌트 메타데이터 규칙으로 메타데이터 수정 절을 참고하자.

모듈 버전(Module version)

모듈 버전은 출시된 모듈의 고유한 변경 사항 집합을 나타낸다. 예를 들어 18.0은 좌표가 com.google:guava:18.0인 모듈 버전을 나타낸다. 실제 모듈 버전 구성 형식에는 제한이 없다. 타임스탬프, 숫자, -GA와 같은 특수 접미사는 모두 허용되는 식별자다. 가장 널리 사용되는 버전 관리 전략은 시멘틱(semantic) 버저닝이다.

플랙폼(Platform)

플랫폼은 함께 사용하기 위한 모듈 세트다. 다양한 사례에 따라 다양한 플랫폼 카테고리가 있다.

모듈 세트: 전체적으로 함께 게시되는 모듈 세트인 경우가 많다. 세트 중 하나의 모듈을 사용한다는 것은 세트의 모든 모듈에 동일한 버전을 사용한다는 것을 의미한다. 예를 들어 groovy 1.2를 사용하는 경우 groovy-json 1.2도 사용하자.
런타임 환경: 함께 잘 작동하는 것으로 알려진 라이브러리 세트다. 예를 들어, 스프링 플랫폼은 스프링과 스프링과 잘 작동하는 컴포넌트 모두에 대해 권장하는 버전이 있다.
배포 환경: 자바 런타임, 애플리케이션 서버, …

또한, 그레이들은 가상 플랫폼을 정의한다.

메이븐 BOM(Bill-of-Material)은 그레이들이 지원하는 널리 사용되는 플랫폼이다.

게시(Publication)

소비자가 사용할 수 있도록 단일 엔터티로 리포지터리에 게시해야 하는 파일 및 메타데이터에 대한 설명이다.

게시에는 명칭이 있으며 하나 이상의 아티팩트와 해당 아티팩트에 대한 정보(메타데이터)로 구성된다.

리포지터리(Repository)

리포지터리는 모듈 세트를 호스팅하며, 각 모듈은 모듈 버전으로 표시된 하나 이상의 릴리스(컴포넌트)를 제공할 수 있다. 리포지터리는 바이너리 리포지터리 제품(예: Artifactory 또는 Nexus) 또는 파일 시스템의 디렉토리 구조를 기반으로 할 수 있다. 자세한 내용은 리포지터리 선언을 참고하자.

분석 규칙(Resolution rule)

분석 규칙은 의존성을 직접 분석하는 방식의 동작에 영향을 준다. 분석 규칙은 빌드 로직의 일부로 정의된다. 자세한 내용은 의존성 분석을 직접 커스텀하는 방법 절을 참고하자.

전이적 의존성(Transitive dependency)

컴포넌트의 변형은 제대로 작동하기 위해 다른 모듈에 대한 의존성(소위 전이적 의존성)을 가질 수 있다. 리포지터리에 호스팅된 모듈의 릴리스는 이러한 전이적 의존성을 선언하는 메타데이터를 제공할 수 있다. 기본적으로 그레이들은 전이적 의존성을 자동으로 분석한다. 전이적 의존성에 대한 버전 선택은 의존성 제약 조건 선언에 의해 영향을 받을 수 있다.

(컴포넌트의)변형(Variant (of a component))

각 컴포넌트는 하나 이상의 변형으로 구성된다. 변형은 아티팩트 세트로 구성되며 의존성 세트를 정의한다. 이는 일련의 애트리뷰트와 기능(capabilities)으로 식별된다.

그레이들의 의존성 분석은 변형을 인식하며 컴포넌트(즉, 모듈의 한 버전)가 선택된 후 각 컴포넌트의 하나 이상의 변형을 선택한다. 변형 선택 결과가 모호한 경우에도 실패할 수 있다. 즉, 그레이들에 여러 상호 배타적 변형 중 하나를 선택할 수 있는 정보가 충분하지 않음을 의미한다. 이 경우 변형 애트리뷰트를 통해 더 많은 정보를 제공할 수 있다. 각 자바 컴포넌트가 일반적으로 제공하는 변형의 예로는 API 및 런타임 변형이 있다. 다른 예로는 JDK8 및 JDK11 변형이 있다. 자세한 내용은 변형 선택 장을 참고하자.

변형 애트리뷰트(Variant Attribute)

애트리뷰트는 변형을 식별하고 선택하는 데 사용된다. 변형에는 하나 이상의 애드리뷰트가 정의되어 있다(예: org.gradle.usage=java-api, org.gradle.jvm.version=11). 의존성이 분석되면 애트리뷰트 집합이 요청되고 그레이들은 의존성 그래프에서 각 컴포넌트에 가장 적합한 변형을 찾는다. 각 값의 호환성을 표현하기 위해 애트리뷰트에 대해 호환성 및 명확성 규칙을 구현할 수 있다(예: 자바 8은 자바 11과 호환되지만 요청된 버전이 11 이상인 경우 자바 11을 선호해야 한다). 이러한 규칙은 일반적으로 플러그인에서 제공된다. 자세한 내용은 변형 선택 및 애트리뷰트 선언 장을 참고하자.