텍스트 기반으로 작성된 문서를 asciidoc 이라고 하는 도구를 이용하여 다양한 형태의 문서로 변환할 수 있는 도구가 있다.

간단간단하게 작성해서 볼 요량이면 마크다운으로도 충분하지만,

스프링부트 레퍼런스문서를 아무런 생각없이 마크다운으로 번역하다보니 스프링부트 레퍼런스문서와 차이가 너무 컸다.

초반에 틀도 제대로 잡지 않고 주먹구구식으로 시작하다보니 아쉬움이 많다. 목차와 섹션 연결도 제대로 안되고...

그래서 다음 스프링부트 1.3.0. 번역은 asciidoc  을 기반으로 하여 각 파트를 나눠서 진행하려고 한다.

스프링에서는 진즉에 asciidoc을 이용해서 레퍼런스문서를 생성해주고 있다.

https://github.com/spring-projects/spring-boot/tree/master/spring-boot-docs

보면서 진즉에 이렇게 했어야 했어! 라는 생각을 하게 된다.


ATOM 에서 asciidoc 형식 문서작성을 도와주지 않을까하고 찾아보니 아니나 다를까 asciidoc-preview라고 하는 패키지가 존재했다. 이 패키지를 이용해서 작성하려고보니 한글...이 안나온다.

정확하게는 사용하는 폰트가 영문폰트니 한글이 지원안된다.

그래서 한글을 나오도록 만들만드는 작업을 했다.

PREFERENCE - PACKAGE - asciidoc-preview - View Code

ATOM  홈디렉토리에 bundle 에 'nanum' 이라는 디렉토리를 생성하고 그 안에 파일들을 복사해 넣었다.

USER_HOME/.atom/packages/asciidoc-preview/bundle/nanum

asciidoc-preview.less 를 열고 아래 폰트항목을 추가했다.

// Nanum 
@font-face {
  font-family: "NanumBarunGothic";
  font-weight: normal;
  font-style: normal;
  src: url("@{nanum-font-path}/NanumBarunGothic.ttf");
}
@font-face {
  font-family: "NanumBarunGothic";
  font-weight: normal;
  font-style: bold;
  src: url("@{nanum-font-path}/NanumBarunGothicBold.ttf");
}
@font-face {
  font-family: "D2Coding";
  font-weight: normal;
  font-style: normal;
  src: url("@{nanum-font-path}/D2Coding.ttc");
}

그리고는 아래 폰트적용 코드들에다가 죄다 위에서 생성한 폰트를 넣어줬다.

pre, code, samp 항목들을 찾아서...

code,
kbd,
pre,
samp {
  font-family: D2Coding, monospace;
  font-size: 1em;
}

그리고나서 리로드Reload 를 수행하면 다음처럼 쫘안~

이제 asciidoc 의 문법을 익혀서 잘 사용하면 되겠다.

아참... 내가 마크다운을 사용하지 않게 된 것이...

ㅡ_-) atom 의 마크다운 프리뷰에서 소스코드 복사가 본문과 함께 되지 않아서다.


'Tools' 카테고리의 다른 글

[log] 싱크패드 울트라나브(블루투스)  (3) 2018.10.25
ZSH - The Z Shell  (0) 2016.05.14

그레들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