Uncategories Gradle Java Quickstart.

Gradle Java Quickstart.

오전 7:13

from : https://docs.gradle.org/current/userguide/tutorial_java_projects.html

1. The Java Plugin 

자바 Gradle는 일반 목적의 빌드 툴이다. 빌드스크립트에 많은 노력을 들이지 않더라도 빌드를 수행할 수 있다. 빌드 스크립트를 추가하지 않는경우 빌드를 수행하지 않는다. 
대부분의 자바 프로젝트는 유사하게 자바소스 파일을 컴파일 해야한다. 테스트를 돌리든지, JAR파일내의 클래스를 생성하든지, 그런대로 나은점은 각 프로젝트마다 이런 모든 코드를 할 필요는 없다는 것이다. 운 좋게도 Gradle는 이런 작업을 하지 않아도 된다. Gradle는 plugins를 이용하여 이러한 문제들을 해결한다. 플러그인은 몇가지 방법으로 프로젝트 설정을 확장한다. 보통 몇가지 사전 설정 작업을 수행함으로 해서 다른 유용한 동작과 함께 수행된다. Gradle는 쉽게 당신의 코드에 추가하거나, 다른 프로젝트와 공유할 수 있도록 플러그인을 제공하고 있다. 이러한 플러그인중 하나는 Java Plugin이다. 이 플러그인은 당신의 프로젝트에 몇가지 태스크를 추가한다. 이것은 컴파일하고 유닛테스트를 수행하고 Jar 파일을 생성하는 작업이다. 
Java Plugin은 관습적인 기반을 갖는다. 이것의 의미는 플러그인은 기본값을 지정하여 프로젝트의 많은 부분에 설정된다. 예를 들면 Java Source Files의 위치를 지정하는 것을 들 수 있다. 이러한 관습을 따른다면 빌드 스크립트를 작성할때 많은 노력을 들지 않아도 된다. Gradle는 관습을 따르지 않기를 원한다면, 프로젝트를 커스터마이즈 하게 해준다. 사실 자바 프로젝트에 빌드를 위해서 모든 플러그인을 사용할 필요가 없다. 이것은 자바 프로젝트의 지원은 플러그인으로 구현되어 있다. 
Gradle은 Java Plugin, 의존성관리, 복합 프로젝트 빌드 등에 대한 많은 부분을 깊이있게 다루고 있다.
이 챕터에서는 일반적인 빌드 관련 사항에 대해서 살펴볼 것이다. 


2. A basic Java project

간단한 예제를 보자. Java Plugin을 이용하기 위해서 다음 내용을 빌드 파일에 넣자. 

Example 7.1. Using the Java plugin
build.gradle
apply plugin: 'java'
Note : 이 예지의 코드들은 samples/java/quickstart 파일에서 찾을 수 있다. 
이 코드는 모든 자바 프로젝트에 정의해야한다. 이것은 Java Plugin을 프로젝트에 적용하고 프로젝트에 몇가지 태스크를 추가할 것이다. 

어떤 태스크들이 가능한가?

gradle tasks를 사용하여 프로젝트의 태스크 리스트를 살펴 볼 수 있다. 이것은 프로젝트에 추가된 Java plugin에 대한 태스크 리스트를 보여준다. 
Gradle는 생성되는 모든 자바 코드는 src/main/java 아래 생성되 있다고 기대한다. 또한 테스트 코드는 src/test/java에 들어 있다고 생각한다. 추가적으로 파일들은 src/main/resources에 들어가며 이는 JAR파일내의 리소스가 들어간다. 테스트를 위해서 필요한 리소스는 src/test/resources 아래 들어가게 된다. 모든 출력 파일들은 build 디렉토리 하위에 들어가며, JAR파일들은 build/libs디렉토리에 최종적으로 만들어진다. 

2.1. Building the project

Java plugin은 몇가지 태스크를 프로젝트에 추가하게 된다.
가장 공통적으로 사용되는 태스크는 build태스크이다. 이것은 프로젝트를 full build를 수행한다. gradle build를 실행하면 Gradle는 컴파일과 테스트를 수행한다. 그리고 메인 클래스와 리소스를 추가한 JAR파일을 생성한다. 

Example 7.2. Building a Java project
Output of gradle build
> gradle build
:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources
:testClasses
:test
:check
:build

BUILD SUCCESSFUL

Total time: 1 secs
몇가지 유용한 태스크는 다음과 같다. 
clean
build 디렉토리를 삭제하고 모든 빌드 파일을 제거한다. 
assemble
컴파일과 jars를 수행한다. 그러나 유닛 테스트는 수행하지 않는다. 다른 플러그인은 이 태스크에 추가적인 artifacts를 추가한다. 예를 들어 War플러그인을 사용하면 이 작업은 WAR파일을 빌드하게 된다. 
check
컴파일과 테스트를 수행한다. 다른 플러그인은 이 작업을 위해 다 많은 체크를 추가한다. 예를 들어 만약 checkstyle플러그인을 수행하면 이 것은 소스코드에 대해서 체크 스타일을 수행한다. 

2.2. External dependencies

일반적으로 자바 프로젝트는 외부 JAR파일들에 의존성을 가지게 된다. 프로젝트에서 이러한 JAR파일들을 참고하기 위해서는 Gradle에 그것을 어디에서 찾을 수 있을지 알려 주어야 한다. Gradle에서는 JAR파일들과 같은 aritifacts 들은 repository에 위치하게 된다. repository는 프로젝트의 의존성을 패칭하기 위해서 사용되어야 한다. 혹은 프로젝트의 아티팩트들을 퍼블리싱 하기 위해서 필요하다. 이 예제에서 우리는 공용 Maven 프로젝트를 사용할 것이다. 

Example 7.3. Adding Maven repository
build.gradle
repositories {
    mavenCentral()
}
몇가지 의존성을 추가해보자. 여기에 우리는 컴파일 시점에 commons collections과 junit을 추가할 것이다. 

Example 7.4. Adding dependencies
build.gradle
dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

2.3. Customizing the project

Java plugin은 프로젝트에 프로퍼티들의 몇개를 추가한다. 이 프로퍼티들은 기본값을 가진다. 이 값들을 가지고 시작을 위해서는 충분하다. 이값들이 적합하지 않을경우 변경하는 것은 매우 쉽다. 우리는 자바 프로젝트의 버젼 넘버를 지정할 것이다. 다음으로 우리는 JAR manifest를 추가할 수 있다.  

Example 7.5. Customization of MANIFEST.MF
build.gradle
sourceCompatibility = 1.5
version = '1.0'
jar {
    manifest {
        attributes 'Implementation-Title': 'Gradle Quickstart',
                   'Implementation-Version': version
    }
}

어떤 프로퍼티들이 가능한가?

gradle properties 를 이용하여 프로젝트의 리스트를 확인할 수 있다. Java plugin에 의해서 추가된 프로퍼티들을 보게 해준다. 
Java plugin이 추가한 태스크는 regular 태스크이다. 빌드파일에 설정된 것과 완젼히 동일하다. 이 의미는 이전 챕터에서 본 이러한 태스크들을 커스터마이즈 하는 메커니즘을 사용할 수 있다는 것이다. 예를 들면 태스크의 프로퍼티를 설정할수 있고 태스크에 대한 행위를 추가하고, 태스크의 의존성들을 벼경하거나 태스크들을 교체할 수 있다. 우리의 예제에서는 test태스크를 설정할 것이다. 이것은 Test의 타입이며 테스트들이 수행되어질때 시스템 프로퍼티가 추가된다.  

Example 7.6. Adding a test system property
build.gradle
test {
    systemProperties 'property': 'value'
}

7.2.4. Publishing the JAR file

보통 JAR 파일들은 어딘가 퍼블리시되어야 한다. 이것을 위해서 Gradle에는 JAR파일에 퍼블리시 될 위치를 알려 주어야 한다. Gradle에서는 JAR파일들과 같은 아티팩트들은 프로퍼티들에 퍼블리시 되어진다. 우리의 샘플에서 우리는 로칼 디렉토리에 퍼블리시 될 것이다. 또한 원격 위치에 퍼블리시 되거나 복합적인 위치에 퍼블리시 되어야 한다. 

Example 7.7. Publishing the JAR file
build.gradle
uploadArchives {
    repositories {
       flatDir {
           dirs 'repos'
       }
    }
}
JAR파일을 퍼블리시 하기 위해서 gradle uploadArchives를 수행하자. 

7.2.5. Creating an Eclipse project

Eclipse-specific 디스크립트 파일들이며 .project와 같은 파일을 생성하는 것이다. 빌드 파일에 다른 플러그인을 추가할 필요가 있다. 

Example 7.8. Eclipse plugin
build.gradle
apply plugin: 'eclipse'
이제 gradle eclipse 커맨들르 실행하여 Eclipse프로젝트 파일을 생성하자. 

7.2.6. Summary

우리의 샘플을 위해서 완벽한 빌드 파일은 다음과 같다. 

Example 7.9. Java example - complete build file
build.gradle
apply plugin: 'java'
apply plugin: 'eclipse'

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

repositories {
    mavenCentral()
}

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

test {
    systemProperties 'property': 'value'
}

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


3. Multi-project Java build

복수 프로젝트 빌드를 살펴보자. 아래 프로젝트 레이아웃을 보자. 

Example 7.10. Multi-project build - hierarchical layout
Build layout
multiproject/
  api/
  services/webservice/
  shared/
  services/shared/
Note : 이 예제의 코드는 samples/java/multiproject에서 찾을수 있다. 
여기에는 4개의 프로젝트를 가지고 있다. api프러덕트는 JAR파일로 XML웹서비스의 Java client 를 담고 있다. webservice는 XML을 반환한다. shared 는 api와 sebservice양쪽에서 사용되는 코드를 담고 있다. services/shared는 shared프로젝트에 의존되는 코드를 담고 있다. 

3.1. Defining a multi-project build

multi-project빌드를 정의하기 위해서는 settings파일을 생성해야한다. 이 settings파일은 소스 트리의 루트 디렉토리에 존재하며, 빌드에 포함될 프로젝트를 지정한다. 이것은 settings.gradle 라 불리며, 이 예제에서는 단순한 계층구조의 레이아웃을 이용하고 있다. 

Example 7.11. Multi-project build - settings.gradle file
settings.gradle
include "shared", "api", "services:webservice", "services:shared"

3.2. Common configuration

대부분의 멀티 프로젝트 빌드를 위해서 몇가지 설정이 있다. 이것은 모든 프로젝트에 공통으로 적용된다. 우리의 예제에서는 루트 프로젝트에 공통 설정을 할것이다. 이것은 configuration injection이라고 불린다. 루트 프로젝트는 컨테이너와 같다. 그리고 subprojects메소드는 이 컨테이너의 엘리먼트들을 순회하며 특정 설정을 인젝트 한다. 이 방법은 모든 아카이브들을 위해 manifest 컨텐츠를 정의하기 쉽게 하고, 몇가지 공통 의존성들을 설정하기 쉽게 해준다. 

Example 7.12. Multi-project build - common configuration
build.gradle
subprojects {
    apply plugin: 'java'
    apply plugin: 'eclipse-wtp'

    repositories {
       mavenCentral()
    }

    dependencies {
        testCompile 'junit:junit:4.12'
    }

    version = '1.0'

    jar {
        manifest.attributes provider: 'gradle'
    }
}
우리 샘플에서는 자바 플러그인을 각 하위 프로젝트에 적용하였다. 이것은 태스크들과 설정 프로퍼티들을 의미하며 이전 섹션에서 보았던 각 서브 프로젝트 내에 설정한 내용들이다. 이제 컴파일과 테스트 그리고 JAR 파일 생성을 gradle build를 통해서 수행할 수 있다. 
또한 이 플러그인들은 subprojects 섹션에서 적용되어지며 루트 레벨에서는 적용이 되지 않는다. 그리고 루트 빌드는 루트 프로젝트 내에서 자바 소스 파일들을 찾을 것으로 기대하지 않는다. 오직 서브 프로젝트에서 찾기를 바란다. 

3.3. Dependencies between projects

동일 빌드내에 프로젝트들 사이에 의존성을 추가할 수 있다. 예를 들면 하나의 프로젝트에 대한 JAR파일이 다른 프로젝트의 컴파일에 사용되어진다. api빌드 파일은 shared프로젝트의 의존성이 추가될 것이다. 때문에 이 의존성에 대해서 Gradle는 프로젝트 shared 프로젝트는 api프로젝트 이전에 빌드를 보장한다.

Example 7.13. Multi-project build - dependencies between projects
api/build.gradle
dependencies {
    compile project(':shared')
}

3.4. Creating a distribution

우리는 배포를 추가할 수 있다. 이것은 클라이언트에 적재 되어진다. 

Example 7.14. Multi-project build - distribution file
api/build.gradle
task dist(type: Zip) {
    dependsOn spiJar
    from 'src/dist'
    into('libs') {
        from spiJar.archivePath
        from configurations.runtime
    }
}

artifacts {
   archives dist
}
Unknown

Share this

Related Posts

Next
« Prev Post
Previous
Next Post »
피드 구독하기: 댓글 (Atom)