2012년에 출시된 groovy 기반으로 한 오픈소스 빌드도구로, 거의 모든 타입의 소프트웨어 (어떤 언어든 상관없이 빌드하겠다)를 빌드할 수 있는 빌드 자동화 시스템이다.
프로젝트를 실행 가능한 어플리케이션으로 만들어주는 툴
소스코드를 컴파일 테스트 , 정적분석 등을 실행하여 실행 가능한 애플리케이션으로 만들어주는 과정이다.
위의 문제점들을 한번에 해결해주는 도구로 계속해서 늘어나는 라이브러리 자동추가 및 관리를 해주며, 프로젝트를 진행하며 라이브러리의 버전을 쉽게 동기화를 해준다.
maven의 상속구조보다 재사용에 용이하고, 프로젝트의 조건을 체크할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있다.
원래는 프로젝트를 맞춰서 모듈을 만든다면, 설정 주입 방식은 모듈을 만들고 프로젝트에 주입한다.
하나의 레파토리지 내에 여러개의 하위 프로젝트를 구성하는 것으로, 보통 프로젝트는 하나이나 멀티 프로젝트 빌드는 레파지토리 하나를 만들고 프로젝트 네 개를 다 관리해준다 : 빌드 속도가 빠르다.
빌드 캐시 : 두 개 이상의 빌드가 돌아가고, 하나의 빌드에서 사용되는 파일들이 다른 빌드들에 사용된다면 gradle은 빌드 캐시를 이용해 이전 빌드의 결과물을 다른 빌드에서 사용할 수 있다.
데몬 프로세스 : 서비스의 요청에 응답하기 위해 오래동안 살아있는 프로세스로 그레이들의 데몬 프로세스는 메모리 상에 빌드 결과물을 보관한다 (이로 인해 한번 빌드된 프로젝트는 다음 빌드에서 매우 적은 시간만 소요된다)
api : 내부 의존성을 컴파일과 런타임 모두에 보이는 API 의존성
implementation : 내부 의존성을 런타임에서만 보이는 구현 의존성, 코드와 직접적으로 연관이있는 라이브러리이다.
compileOnly : 컴파일에만 사용되는 의존성 정의 > 실제 구동되는 프로그램으로 만들때만 사용한다.
runtimeOnly : 런타임에만 사용되는 의존성 정의 > 프로그램이 진짜 구동될 때 시작될 때만 사용되는 라이브러리이다.
의존성이란 B객체가 A객체를 사용하는 것을 의미한다. 해당 이미지에서 화살표가 나가는 쪽이 의존하고 있는 것인데 여기서 내부라는 것이 붙은 것은 B가 A를 의존, 즉 B가 A를 라이브러리로 사용한다고 했을 때 이것을 C가 볼 수 있는지의 여부라고 보면 된다. API는 이런 의존성을 컴파일과 런타임 모두에 보이게 되고 implementation는 컴파일시에는 보이지 않게 된다.
이러한 implementation 경우에는 의존성을 최소화하였기 때문에 빌드 속도에도 도움이 된다. API는 A가 수정되었을 시 B까지 해당 내용을 알고 있기 때문에 B 뿐만 아니라 C까지 모두 영향을 끼친다. implementation 같은 경우 내부 의존성이 컴파일 타임에 진행되지 않으므로 B까지만 영향을 끼치기 때문이다.
이것들을 해결하기 위해 런타임때 쓰는 라이브러리 컴파일 때 쓰는 라이브러리를 구분해서 만든 것이다.