Gradle - Java Quick Start

The Java plugin

Gradle은 일반적인 목적에 맞는 빌드 툴입니다. 빌드 스크립트를 통해서 깔끔하게 빌드를 수행할 수 있다. 하지만 만약 빌드 스크립트에 코드를 추가하지 않는다면 어떠한 빌드도 수행하지 않을 것이다.

대부분의 자바 프로젝트는 기본적으로 매우 유사하다. : 자바 소스 파일을 컴파일할 필요가 있고, 유닛 테스트를 수행해야 하며 클래스들을 포함한 JAR 파일을 생성해야 한다. 모든 프로젝트를 위해 이러한 코드를 매번 작성한다면 그것은 좋지 않을 것이다. Gradle은 이러한 문제를 plugin을 사용함으로써 해결한다. 플러그인은 Gradle의 extesion이다. 일반적으로 함께 사용하면 유용할 미리정의한 task들을 추가해준다. 자바 플러그인은 그러한 플러그인 중 하나이다. 자바 플러그인은 자바 소스를 컴파일하고 유닛 테스트하고 JAR로 패키징하는 타스크들을 추가해준다.

자바 플러그인은 컨벤션 기반이다. 이 의미는 플러그인이 프로젝트의 많은 관심사들을 해결하기 위해 기본 값을 사용한다는 것이다. 만약 프로젝트가 규칙을 따르지 않는다면 빌드는 정상적으로 동작할 수 없을 것이다. Gradle은 규칙을 따르지 않도록 커스터마이징할 수 있다. 만약 자바 프로젝트를 빌드하기 위해서 자바 플러그인을 사용하지 않길 원한다면 그렇게 해도 좋다. 

A basic Java project

간단한 예제를 살펴보자. 자바 플러그인을 사용하기 위해 빌드 스크립트에 다음과 같이 추가한다.

apply plugin: 'java'

이것이 자바 프로젝트를 정의하기 위해 필요한 모든 것이다. 다음과 같이 정의하므로서 프로젝트를 위한 많은 타스크들이 추가 될 것이다.

Gradle은 프로덕션 소스코드를 src/main/java에서 테스트를 위한 소스 코드를 src/test/java에서 찾으려고 시도할 것이다. 추가적으로 /src/main/resources 에서 파일과 같은 JAR에 포함될 리소들을 src/test/resources 에서 테스트를 수행하기 위한 리소스들을 찾을 것이다. 모든 결과 파일들은 build디렉토리에 생성되며 최종적으로 JAR로 패킹되어 build/libs 디렉토리에 생성될 것이다.

Building the project

자바 플러그인은 프로젝트를 위해 몇몇의 타스크들을 추가할 것이다. 하지만 프로젝트 빌드를 위해서 사용할 것은 손에 꼽을 만한 타스크들일 것이다. 대부분 build 타스크를 사용할 것이다. gradle build 커맨드를 수행하면 Gradle은 소스 코드를 컴파일하고 테스트하며 main 디렉토리 하위의 클래스들과 리소스들을 jar 파일로 패키징한다.

toddsonui-MacBook-Pro:gradle-test devsun$ gradle build

:compileJava UP-TO-DATE

:processResources UP-TO-DATE

:classes UP-TO-DATE

:jar

:assemble

:compileTestJava UP-TO-DATE

:processTestResources UP-TO-DATE

:testClasses UP-TO-DATE

:test UP-TO-DATE

:check UP-TO-DATE

:build

BUILD SUCCESSFUL

Total time: 2.47 secs

다른 몇가지 유용한 타스크들은 다음과 같다.

clean - 빌드 디렉토리를 삭제한다. 

assemble - 소스코드를 컴파일하고 jar로 패킹한다. 그러나 유닛테스트는 실행하지 않는다. 다른 플러그인들의 더많은 아티펙트들을 이 타스크를 위해 추가한다. 예를 들어 war 플러그인을 사용하면 이 타스크는 이 타스크는 프로젝트를 WAR 파일로 빌드할 것이다.

check - 소스 코드를 컴파일하고 테스트 한다. 다른 플러그인들은 이 타스크를 위해 더많은 체크들을 추가한다. 예를 들어 checkstyle 플러그인을 이용하면 소스코드에 CheckStyle을 수행할 것이다.

External dependencies

일반적으로 자바 프로젝트는 외부 JAR파일에 대한 디펜던시를 가진다. 프로젝트에서 이러한 JAR 파일들을 참조하기 위해 Gradle에게 어디에서 해당 찾을지를 알려줘야 한다. Gradle에서는 그러한 JAR 파일들을 아티펙트라고 하며 아티펙트들이 위치한 곳을 리파지토리라고 한다. 리파지토리는 프로젝트를 위한 디펜던시를 패티하거나 프로젝트의 아티펙트를 퍼블리싱하기 위해 이용된다. 이번 예제에서는 퍼블릭 메이븐 리파지토리를 이용할 것이다.

repositories {
    mavenCentral()
}

몇몇의 디펜던시를 추가해보자. 프로덕션 클래스를 위한 컴파일 타임 디펜던시로 commons collections와 테스트 클래스들을 위한 컴파일 타임 디펜던시로 junit을 설정해보자.

dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

Customizing the project

자바 플러그인은 프로젝트를 위해 많은 수의 프로퍼티들을 추가한다. 이러한 프로퍼티들은 그냥 시작하기 위해 충분한 기본값들을 지정하고 있다. 만약 이러한 내용들이 적합하지 않다면 쉽게 변경할 수 있다. 자바 프로젝트의 버젼을 명시하고 소스가 따르는 자바 버젼을 명시한 예이다. 또한 JAR manifest을 위해 몇가지 속성들을 추가한 예이다.

sourceCompatibility = 1.5
version = '1.0'
jar {
    manifest {
        attributes 'Implementation-Title': 'Gradle Quickstart',
                   'Implementation-Version': version
    }
}

자바 플러그인이 추가한 타스크들은 정식 타스크들이다. 이것은 의미는 이러한 타스크들을 커스터마이징하기 위해서 이전 챕터에 설명한 매커니즘을 사용한다는 의미이다. 예를 들어 타스크의 프로퍼티를 세팅할 수 있고, 타스크를 위한 동작을 추가할 수 있고 타스크의 디펜던시를 변경할 수 있고 타스크 전체를 교체할 수도 있다는 것이다. 우리는 tesk 타스크를 정의하는데 테스트시 노출할 시스템 프로퍼티를 추가할 것이다. gradle properties 명령을 통해서 프로젝트의 프로퍼티 리스트를 출력할 수 있다.

test {
    systemProperties 'property': 'value'
}

Publishing the JAR file

일반적으로 JAR 파일은 어떤 지역에 퍼블리시될 필요가 있다. 이러한 일을 수행하기 위해서 Gradle에 JAR파일이 퍼블리시될 위치를 알려줄 필요가 있다. Gradle에서는 JAR 파일과 같은 아티펙트들을 리파지토리에 퍼블리시 한다. 샘플은 로컬 디렉토리로 퍼블리시 한 예이며, 리모트 혹은 다수의 장소에 퍼블리시 할 수 있다.

uploadArchives {
    repositories {
       flatDir {
           dirs 'repos'
       }
    }
}

Creating an Eclispe project

Eclipse 기반 디스크립터를 생성하기 위해, 다음과 같은 플러그인을 적용할 수 있다. gradle eclipse 커맨드를 이용하여 이클립스 프로젝트 파일을 생성할 수 있다.

apply plugin: 'eclipse'

Multi-project Java Build

일반적인 멀티프로젝트 빌드에 대해서 살펴보겠다.

multiproject/
  api/
  services/webservice/
  shared/
  services/shared/

여기 우리는 4개의 프로젝트를 가지고 있다. Project api는 XML 웹서비스를 위한 자바 클라이언트를 제공하는 클라이언트를 탑재한 JAR 파일을 생성한다. 프로젝트 webservice는 XML을 결과를 반화하는 webappd이다. 프로젝트 shared는 api와 webservice에서 사용되는 코드들을 포함한다. 프로젝트 servicee/shared는 shared 프로젝트에 디펜던시를 가진다.

Defining a multi-project build

멀티 프로젝트 빌드를 정의하기 위해서 우리는 settings 파일을 생성할 필요가 있다. settings 파일은 소스 트리의 로트 디렉토리에 위치하며, 빌드에 포함되는 프로젝트들을 명시한다. 이름은 settings.gradle 이다. 예를 들어 위의 예를 위한 세팅 파일은 다음과 같다.

include "shared", "api", "services:webservice", "services:shared"

Common Configuration

대부분의 멀티 프로젝트들은 모든 프로젝트들을 위한 공통 설정을 가지고 있다. 우리의 예제에서 루트 프로젝트에 이러한 공통 설정을 정의할 것이다. 이러한 기술을 configuration injection이라고 한다. 여기 루트 프로젝트는 컨테이너처럼 그들의 엘리먼트의 subprojects 메소드들을 이터레이션하면서 호출한다. 이러한 방법으로 모든 아카이브에서 대한 매니페스트를 쉽게 정의할 수 있다.

subprojects {
    apply plugin: 'java'
    apply plugin: 'eclipse-wtp'

    repositories {
       mavenCentral()
    }

    dependencies {
        testCompile 'junit:junit:4.11'
    }

    version = '1.0'

    jar {
        manifest.attributes provider: 'gradle'
    }
}

각 서브 프로젝트들에 대해 자바 플러그인을 적용하였다. 이것은 타스크와 설정들이 각 서브프로젝트에 적용되었다는 것을 의미한다. 루트 프로젝트의 gradle build를 수행함으로써 모든 프로젝트들은 compile, test, JAR 파일 생성을 수행할 것이다.

또 이러한 플러그인들이 subprojcets 섹션에만 적용된 것을 유의하자. 루트 레벨이 아닌 이유는 루트에는 자바 소스가 존재하지 않고 서브프로젝트에만 존재할 것이라는 가정이 있기 때문이다.

Dependencies between projects

같은 빌드에서 프로젝트간 디펜던시가 필요할 경우가 있다. 다음과 같은 설정에 따라 해당 프로젝트가 빌드하기 전에 shared 프로젝트가 빌드하게 되는 설정은 다음과 같다.

dependencies {
    compile project(':shared')
}

Creating Distribution

배포판을 추가하기 위해 다음과 같이 설정을 추가할 수 있다.

task dist(type: Zip) {
    dependsOn spiJar
    from 'src/dist'
    into('libs') {
        from spiJar.archivePath
        from configurations.runtime
    }
}

artifacts {
   archives dist
}