현재 개발하고 있는 프로젝트의 빌드도구는 그레이들GRADLE(https://gradle.org/) 이다.

그리고 프로젝트를 빌드할 때 사용되는 것은 프로젝트 안에 포함되어 있는 그레이들 래퍼Gradle wrapper 이다.

그레들 래퍼를 이용해서 빌드환경에 별도로 그레이들을 설치하지 않아도 그레이들의 빌드를 이용할 수 있다. 이때, 시스템변수를 읽어들이는데 그 중 영향을 받는 것 중에 하나가 JAVA_HOME 변수다.

이 빌드에 사용되는 JAVA_HOME 변수 정보를 gradle.properties 에 정의하여 빌드 시에만 참조하도록 할 수 있다.

특정 프로젝트를 $PROJECT_HOME 이라고 했을 때, 프로젝트 상위경로에 gradle.properties 를 생성하고

org.gradle.java.home=<JAVA_HOME 경로>

을 지정해두면 빌드시 그레이들의 JAVA_HOME 변수를 대체하게 된다. 이 프로젝트를 버전관리하고 있다면 gradle.properties 는 무시ignore 처리를 해두면, 개발자마다 미묘하게 다른 JAVA_HOME 경로를 프로젝트별로 정의하는 것이 가능해진다.

그레들Gradle 2.6을 처음 실행하면 하단에 다음과 같은 문구가 나온다.

honeymon@honeymon-blog (develop)*$ ./gradlew check
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:backend:compileJava UP-TO-DATE
:backend:processResources UP-TO-DATE
:backend:classes UP-TO-DATE
:backend:compileTestJava UP-TO-DATE
:backend:processTestResources UP-TO-DATE
:backend:testClasses UP-TO-DATE
:frontend:compileJava UP-TO-DATE
:frontend:processResources UP-TO-DATE
:frontend:classes UP-TO-DATE
:frontend:jar UP-TO-DATE
:backend:test UP-TO-DATE
:backend:check UP-TO-DATE
:frontend:compileTestJava UP-TO-DATE
:frontend:processTestResources UP-TO-DATE
:frontend:testClasses UP-TO-DATE
:frontend:test UP-TO-DATE
:frontend:check UP-TO-DATE
 
BUILD SUCCESSFUL
 
Total time: 11.503 secs
 
This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.6/userguide/gradle_daemon.html

이 빌드가 더 빨라질 수 있다, 그레들 데몬은 실행하는 것을 고려하라!https://docs.gradle.org/2.6/userguide/gradle_daemon.html

그레들 빌드가 조금 굼뜬 느낌이 있었는데, 빨라진다면!! 바로 위의 링크로 이동했다.

글을 쭈욱 내리고 '난이도'를 살펴봤다.



아래 명령어만 운영체제에 맞춰서 커맨드라인에서 실행하면 된다. 그레들 홈디렉토리에 데몬실행속성을 활성화하는 (org.gradle.daemon=true) gradle.properties 파일을 추가생산하는 것으로 간단하게 처리가 되었다.

  • Windows

    (if not exist "%HOMEPATH%/.gradle" mkdir "%HOMEPATH%/.gradle") && (echo "org.gradle.daemon=true" >> "%HOMEPATH%/.gradle/gradle.properties")
  • Linux or Unix

    touch ~/.gradle/gradle.properties && echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties

The Gradle Daemon is not enabled by default. However, once it is enabled it is sometimes desirable to disable for some projects or for some build invocations.

그레들 데몬은 기본설정은 활성화되지 않는다. 그러나, 한번 활성화 되고 나면 몇몇 프로젝트 빌드요청에서는 비활성화 하고 싶을 것이다.

The --no-daemon command line switch can be used to force that a Daemon not be used for that build. This is rarely used, but can sometimes be useful when debugging issues with certain builds or Gradle plugins. This command line switch has the highest precedence when considering the build environment.

커맨드라인 스위치 --no-daemon 강제로 사용하는 데몬을 빌드시 사용하지 않도록 할수 있다. 이것은 거의 사용되지 않고, 특정 빌드 또는 Gradle 플러그인 문제를 디버깅 할 때 때때로 유용 할 수 있다.

보다 상세한 내용은, https://docs.gradle.org/2.6/userguide/gradle_daemon.html 를 읽어보시길...

그레들로 프로젝트의 테스트를 실행할때마다
테스트에서 사용하는 자원파일을 찾을 수 없다고 나오길래

왜 못찾는 것이냐?

라고 무시하고(?) 넘어간지 3개월여만에...
그레들 문서(https://docs.gradle.org/current/userguide/java_plugin.html)를 보면서 확인한지 30여분만에 문제를 발견.

src/test/resource

...

src/test/resources

였어야 했는데 말이지...!!! 크앙!!
결함이 발생하던 테스트들 수정하고 정상동작하는 것 확인.

그런데 말입니다.
왜 유닛테스트는 통과되었던거지??


코드의 품질을 높이기 위해서 많이 사용되는 것이 코드에 대한 정적분석을 통해서 코드의 품질을 평가하는 것이다.

코드정적분석에 사용되는 도구로는 checkstyle, findbugs, PMD 등 이 있다. 그레들gradle에 checkstyle, PM 를 추가하는 방법을 설명한다.

1. checkstyle

1.1. 사용방법

1.1.1. gradle's checkstyle 플러그인 추가

apply plugind: 'checkstyle'

build.gradle 파일에 플러그인을 추가한다.

1.1.2. checkstyle.xml 작성

1.1.3. build.gradle 파일에 checkstyle 태스크를 정의한다.

checkstyle {
  ignoreFailures = true // 분석결과 예외가 발생하면 빌드실패 발생시키는 것을 제외
    configFile = file("checkstyle.xml") // 1.1.2 에서 작성한 checkstyle 파일 지정
    reportsDir = file("${buildDir}/checkstyle-output") // 리포트 파일이 위치할 디렉토리 지정
}
 
checkstyleMain {
    reports {
        xml.destination = file("${checkstyle.reportsDir}/checkstyle-report.xml") // 리포트 파일의 위치 및 파일명 지정
    }
}

1.1.4. checkstyle 실행

$ gradle check

checkstyle 플러그인을 추가하면 그레들의 check 태스크를 수정하여 checkstyle 의 checkstyleMain, checkstyleTest 들을 실행시킨다.

1.2. 태스크Tasks

Task nameDepends onTypeDescription
checkstyleMainclassesCheckstyleRuns Checkstyle against the production Java source files.
checkstyleTesttestClassesCheckstyleRuns Checkstyle against the test Java source files.
checkstyleSourceSetsourceSetClassesCheckstyleRuns Checkstyle against the given source set's Java source files.

1.3. checkstyle.xml 기본구조

<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
          "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
          "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
 
<module name="Checker">
    <property name="charset" value="UTF-8" />
    <property name="severity" value="warning" />
    <property name="fileExtensions" value="java, properties, xml" />
 
    <module name="TreeWalker">
        <!-- 사용되는 모듈과 모듈속성을 정의-->
    </module>
</module>

2. PMD

2.1. 사용방법

2.1.1. gradle's pmd 플러그인 추가

apply plugind: 'pmd'

build.gradle 파일에 플러그인을 추가한다.

2.1.2. pmd 태스크의 속성을 정의한다.

pmd {
  ignoreFailures = true // 분석결과 예외가 발생하면 빌드실패 발생시키는 것을 제외
    reportsDir = file("${buildDir}/pmd-output")
}
 
pmdMain {
    reports {
        xml.destination = file("${pmd.reportsDir}/pmd-report.xml")
        xml.enabled = true
    }
}

2.1.3. 실행

$ gradle check

PMD 플러그인이 check 태스크에 의존성을 추가한다.

2.2. 태스크Tasks

태스크명의존유형설명
pmdMain-Pmd출시 소스파일을 대상으로 PMD 실행
pmdTest-Pmd테스트 소스파일을 대상으로 PMD 실행
pmdSourceSet-Pmd지정된 소스셋SourceSet을 대상으로 PMD 실행

3. 정리

checkstyle과 pmd 에서 생성한 XML 보고서는 JENKINS에서 사용하기 위한 분석데이터로 사용된다.

JENKINS에서 checkstyle, pmd 플러그인을 설치한 후 report.xml 경로를 지정한 후



빌드가 정상적으로 진행되면서 분석문서가 생기면 다음과 같은 항목들이 왼쪽 메뉴에 추가가 되고,



각각의 결과를 확인할 수 있다.




○ 참고문헌


그레들Gradle에는 래퍼Wrapper라고 하는 운영체제에 맞춰서 그레들 빌드를 수행하도록 하는 배치 스크립트가 있다.
이 배치스크립트는 프로젝트 내에 숨김속성을 가지고 있는 gradle-wrapper.jar 를 이용해서

project
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle

운영체제에 적절한 배치 스크립트를 실행하도록 한다.

  • 윈도우: gradlew.bat
    > gradlew.bat [task]
    
  • 리눅스 및 OSX: gradlew
    $ ./gradlew [task]
    

프로젝트의 성격에 맞춰 사용할 래퍼의 버전을 변경할 수 있도록 별도의 태스크Task를 작성실행할 수 있다.
프로젝트에 위치한 build.gradle 파일의 마지막 부분에 다음과 같이 wrapper 태스크를 추가한 후,

ext {
    gradleVersion= '2.1' //자신이 원하는 Gradle 버전에 맞춰 변경
}

//...중략

task wrapper(type: Wrapper) {
    gradleVersion = "$gradleVersion"
}

wrapper 태스크를 실행하면 된다.

$ gradle wrapper

● 참고


+ Recent posts