ANT란?

출처-http://blog.naver.com/PostList.nhn?blogId=mir2050&from=postList&categoryNo=11

이 문서는 위의 책에서 번역하였으므로 저작권자는 위의 저자에게 있다.

 

저작권 문제는 법률을 잘 모르는 바 말씀드릴 수 가 없겠습니다.

하여튼 저의 노력이 여러분에게 조금이나마 도움이 되면 그것으로 끝입니다.

이번에는

이 책 5장에 있는

제5장 Ant와 CVS에 따른 자동 빌드와 테스트

에 대하여 번역 합니다.

이번에는 번역기를 쓰지 않았으므로 좀 더 많이 이해가 안가시겠지만, 뭐 그런데로읽을만 합니다.

 

번역자: 이성우 (아이디명:마즈다)

메일: mazda_db@hotmail.com

메신저:엠에스엔 아이디 위와 같음.

 

 

Ant와 CVS에 따른 자동화 빌드와 테스트

 

5.1Ant의 개요

 

5.1.1 Ant란

 앤트는, 자카르타 프로젝트에서 개발되어져 있는 프로그램 소스의 빌드 툴입니다. 빌드 툴은, make명령과 같은 툴을 가르킵니다. 앤트는 make커맨드와는 달리 자바에서 작성되어져 있습니다. (make는 C언어) 같게 자카르타 프로젝트에서 개발되어 있는 서블릿 엔진의 톰켓에서, 앤트는 빌드 툴의 역활을 하고 있습니다. 톰켓의 소스로부터 빌드한 사람들은 앤트를 사용하고 있습니다.

 

5.1.2 왜 앤트인가

 IDE(통합환경구축)을 사용하고 있는 분은, 빌드 툴 같은 것을 사용하고 있을지 모름니다. 그리고 make를 사용하고 있는 분은, 앤트는 특별히 필요하지 않을지도 모릅니다. 여기서 “구태여 앤트를 수용할 5개의 이점”에 대하여 설명드리겠습니다.

 

멀티 플랫폼

 앤트와 파일의 취급을 포함하고, 거의전부의 처리를 자바로 해야 하는 경우, 자바가 인스톨되어있는 환경이 있다면, 어디라도 동작합니다. Windows NT/2000에서 개발된 것을 Linux나Solaris에, 또는 그 반대의 경우에도 부드럽게 이동하는 것이 가능합니다. 그것은 자바자신이 플랫폼 비의존적하기 때문입니다. 빌드 툴이 시스템에 의존하면 안됩니다.

 

충실한 기능(계층화된 디렉토리의 취급)

 앤트에서는, 자바의 패키지 디렉토리와 같은, 계층화된 소스를 빌드하는데, 편리한 fileset, patternset이라고 하는 짜넣는 기능이 준비되어 있습니다. 이것을의 기능을 사용하려면, 와일드 카드를 사용해서 다계층의 소스트리를 용이하게 취급할 수 있습니다.

 

작업의 표준장비

 앤트에서는, 표준으로 50개 가까운 작업(실행할수있는 처리)이 준비되고 있고, option이라고 불리는 작업도 20개 이상 있습니다. 작업에서는, 파일의 복사나 이동, javac, java, javadoc 라는 기본적인 것 부터, CVS, JUnit, Telnet, Sound에 이르는 여러가지 종류가 있습니다. 새로운 작업은 게속해서 개발되고 있고, 오리지날 작업도 비교적 간단히 작성할 수 있습니다.

 

빠른 javac 컴파일

 앤트는, javac를 커멘드로 하지 않고 라이브러리로 작동하기 위에, make커멘드등에서 javac를 작동하는 것보다도 빠르게 컴파일하는것이 가능합니다. 또는, 옵션에서 의존관계를 해석해서 컴파일하는 것이 가능하기 때문에, 대규모의 프로젝트를 하루에도 몇번이라도 빌드하는 것과 같은 경우에 특히 좋습니다.

 

XML에 따른 빌드 규칙의 기술

 make커멘드는, 독자적인 형식으로 Makefile을 기술하고 있습니다. Makefile는 plain text에서 기술 가능하고, 각종 코맨드를 자유로이 호출되어지는 반면, 인덴트의 탭을 사용할수 없는 플랫폼에서는 제약이 있습니다. 또, 복잡하게 쓰여지게 되는 가능성도 있습니다. 앤트는, make코멘드와는 달리, XML으로 빌드 규칙이 쓰여져 있습니다. XML에서 기술하기 때문에, 포맷에따라 문제가 발생하지 않습니다. 게다가, XML을 이해하고 있다면, 가독성도 높습니다.

 

참고:

앤트의 약점

앤트에서는, make와 비교해서 뒤떨어지진다고 생각되는 점이 몇개 있습니다.

▪ 디폴트 규칙을 지정할 수 없습니다.

▪ 인수에서 파일명을 건네서 개별에 컴파일 하는 것이 귀찮습니다.

▪ make파일안에서 사용하는 변수의 연산자가 없습니다.

▪ XML의 기본적인 지식이 필요합니다.

▪ 준비되어 있는 작업에서 처리할수 없는 경우 그것에 대한 대응이 귀찮습니다.

 

 위에 쓰여진것 같이 앤트에 신경쓰이는 경우는, 디렉토리의 것에는 make파일을 준비하고, 개개의 소스의 개발은 make로, 전체의 빌드는 Ant로 하는 것도 가능합니다. 처음부터 멀티 플랫폼으로 전제된 개발한다면, 앤트의 사용을 검사해 두는 것이 유리한 방법입니다.

 

5.2 앤트의 설치

 앤트에는 여러개의 배포방법이 존재합니다. 여기에서는, 각각의 배포형태에 맞는 설치 순서에대하여 설명합니다.

 

5.2.1 얻는 곳(현재 2002-09-17 버전은 1.5까지 나왔습니다.)

 앤트는, 자카르타 프로젝트의 웹사이트로부터 받습니다. 배포형태에는, 소스, 바이너리(jar), RPM(Linux의 배포버전)의 3종류가 있습니다. 각각의 배포처에 대하여는, 표 5-1을 참고해 주십시요. 앤트는, 코어의 부분과 옵션의 부분에 jar파일이 따로 있습니다. 바이너리 인스톨의 경우, 코아 부분과 옵션부분의 파일이 있기 때문에, 옵션의 작업을 사용하는 경우에는, Jakarta-ant-1.3-bin.zip(tar.gz)와 함께 jarkarata-ant-1.3-optional.jar도 다운로드할 필요가 있습니다. JUnit작업은 옵션에 포함하고있기 때문에 , 필연적으로 옵션도 다운로드하는게 됩니다. 표 5-2는 배포형태의 파일 일람입니다.

 

표 5-1 앤트를 얻는 곳

배포형태

얻는 곳

소스

http://jakarta.apache.org/builds/Jakarta-ant/release/v1.3/src/

바이너리(jar)

http://jakarta.apache.org/builds/Jakarta-ant/release/v1.3/bin/

RPM

http://jakarta.apache.org/builds/Jakarta-ant/release/v1.3/rpms/

 

표 5-2 배포파일 일람

배포형태

파일

소스

jakarta-ant-1.3-src.tar.gz 또는 Jakarta-ant-1.3-src.zip

바이너리(jar)

jakarta-ant-1.3-src.tar.gz 또는 Jakarta-ant-1.3-bin.zip,

jakarta-ant-1.3-optional.jar

RPM

ant-1.3.2.noarch.rpm, ant-1.3-2.src.rpm,

ant-manual-1.3-2.noarch.rpm

 

5.2.2 필요한 클래스라이브러리

 앤트를 인스톨하기 전에 준비가 필요한 클래스라이브러리가 몇개가 있다. 이번의 목적은JUnit에서 자동테스트이기 때문에, JUnit를 인스톨 할 필요가 있습니다. 또는 나중에JUnitReport를 사용하기 위해서, XML파서의 Xerces for Java와 XSLT프로세서의 Xalan을 인스톨해 둡니다. Xerces for Java와 Xalan은 표5-2의 URL로 부터 얻으실수 있습니다. 앤트의 메뉴얼에 따르면, Xerces의 2.x, Xalan의 version 2.x에 대응하는것 같습니다만, 여기에서는 함께 1.x의 버전을 사용하는 것으로 하겠습니다.

 Xerces for Java과 Xalan또, 바이너리를 얻어서, 아카이브를 전개한 후, $JAVA_HOME/jre/lib/ext이하에 jar파일을 이동시킴니다. 그리고 적당한 디렉토리에 jar파일을 이동시켜서 환경변수 CLASSPATH에 설정해 둡니다.

 

표 5-3 Xerces for Java 와 Xalan을 얻는곳

Xerces for Java(1.x)

http://xml.apache.org/xerces-j/

Xalan 1.x

http://xml.apache.org/dist/xalan-j/old/

 

 

5.2.3 인스톨

 각 파일을 다운로드할수 있다면, 인스톨을 시작합니다. 인스톨의 방법은 어떤 파일을 다운로드 하는가 에 따라 달라지기 때문에 개별적으로 설명합니다.

 

소스를 받았던 경우

소스에는 2종류의 압축방식의 파일(tar.gz와 zip)이 있기때문에, 적당한 압축풀기툴로 압축을 풉니다. 압축을 푼 후는 jakarta-ant-1.3이라고 하는 디렉토리가 만들어 집니다. 앤트를 소스로부터 빌드하는 경우, junit.jar가 들어있는 곳에 클래스패스를 추가해주던지, 또는 jakarta-ant-1.3/lib/optional이하에 junit.jar를 복사해 둡니다. Xerces, Xalan도 필요한 경우면 클래스패스에 추가시켜 주시거나. 또는, JDK의 인스톨디렉토리를 환경변수 JAVA_HOME에 설정시켜 주십시요.(주:제 경험상으로는 마지막 방법이 좋습니다.)

 UNIX계의 경우에는 jakarta-ant-1.3/build.sh를, Windows계의 경우는 jakarta-ant-1.3/build.bat을 실행시키면, 문제가없는경우에는 jakarta-ant-1.3/dist 이하에 bin, lib디렉토리가 작성되고, 앤트의 실행파일및 jar파일이 작성됩니다.

 앤트를 빌드한 후, dist디렉토리를 앤트등의 이름으로 변경해서 인스톨하려는 곳에 복사해 주십시요. 예를 들면, UNIX계의 경우는 /usr/local/ant, Win계의 경우에는 c:\java\ANT로 이름을 주는 것입니다.

 

바이너리 파일을 받았던 경우

 바이너리 디렉토리 버전을 풀어서, 인스톨될곳에 복사합니다. 디렉토리의 이름은 ant라고 해두는 편이 좋겠습니다. optional.jar는 따로 lib디렉토리에 둡니다.

 

RPM을 받았던 경우

 noarch.rpm의 경우는, rpm –ivh ant-1.3-2.noarch.rpm의 Linux의 rpm커맨드를 입력해서,작성된 jar파일을 인스톨 합니다. src.rpm의 경우는, rpm – rebuild ant-1.3-2.src.rpm의 커맨드를 입력해서, 소스로 부터 빌드를 행해서 패키지로써 인스톨합니다.

 각 배포형식의 인스톨이 끝나면, 환경변수 ANT_HOME을 설정합니다. ANT_HOME은, UNIX계의 경우는 /usr/local/ant, Windows계의 경우에는c:\java\ANT등으로 합니다. 다음에, $ANT_HOME/bin디렉토리에서 ant –help라고 실행해 봅시다 HELP 메세지가 표시되는 경우는 인스톨이 완료된 것입니다.

 

참고: Windows환경에서 UNIX와 같은 수준의 shell환경

 Ant는 커멘드 지향의 툴이기 때문에, UNIX계에서는 물론입니다만, Windows환경에서도 커맨드라인에서의 사용이 기본으로 되어 있습니다.

Windows표준의 커멘드 프롬프트에서는, Windows 9x의 command.com과 Windows NT/2000의 cmd.exe가 있습니다만, 어느것도 UNIX의 환경에 비교해서 매우 빈약합니다.

 그래서, Windows환경에 UNIX와 같은 수준의 툴환경이 제공되고 있는 Cygwin이라는 툴이 있습니다. 커멘드프롬프트의 빈약점을 느끼신다면, 인스톨해 보시는 것도 좋으리라 생각됩니다.

http://www.cygwin.com/

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5.3 Ant의 시작

 이제는, Ant를 사용전의 준비로 부터, 최초의 타겟트를 기술하는 점까지를 설명합니다.

 

5.3.1 사전준비

 우선 처음에, 간단한 프로젝트에서 실제에 Ant를 사용해봅시다. 여기서는, JUnit에 딸려있는Money클라스를 사용하는 것으로 하겠습니다. Money클래스는, JUnit의 압축파일중junit/samples/money 에 있습니다. Money클래스에는 전부 세개의 파일과 한개의 테스트가 포합되어 있습니다.

 디렉토리 구성은, 그림 5-1와 같습니다. JUnit의 samples디렉토리에는 다른 샘플파일도 포함되어 있습니다만, 이번에는 money이하의 디렉토리만을 사용합니다. 또, class파일은 불필요하기 때문에 삭제해 주십시요.

 Ant에서는 소스가 들어있는 디렉토리와, 빌드를 행하는 디렉토리, 생성물을 두는 디렉토리를 분리하는 것이 관습적으로 되어있습니다. 이번에도 용도별로 디렉토리를 분리하는 것으로 합니다. 다만, 소스화일이 들어 있는 디렉토리 이외는 빌드 할때와 빌드 종료후에 일시적으로 필요한 디렉토리가 있기 때문에, Ant에서 동적으로 작성하는 것도 있습니다.

 

Money/              Money클래스디렉토리

 

src/               소스파일이 들어있는 디렉토리

 

                     junit/

                    

                                samples/

 

                                          money/

 

                                                     (java 소스)

 

 

build/             소스빌드용 디렉토리(별도작성)

 

dist/               생성물이 들어 있는 디렉토리(별도작성)

 

그림 5-1 money클래스의 디렉토리 구성

 

5.3.2 build.xml의 작성

 Ant의 빌드 규칙은, 통상 build.xml이라고 하는 파일에 쓰여져 있습니다. Ant자신의 빌드에 사용하는 것도 쓸 수 있고, build.xml의 샘플에서 Ant의 build.xml을 사용하는 것도 할 수 있습니다만, 여기서는 조금씩 모아서 써 봅니다.

 

5.3.3 XML선언

 우선, XML파일로써 필요한 XML선언부를 기술 합니다. 파일중에 커멘트를 한국어로 기술하고 싶을 경우에는, 사용하는 인코딩도 지정합니다. (리스트 5.1)

 

리스트5.1 XML 선언부

<?xml version=”1.0” encoding=”KSC5601”?>

 

5.3.4 project

 build.xml의 루트 요소는 project 입니다. Project에는 프로젝트 이름, 디폴트에서 실행하는 작업명, Ant를 실행하는 베이스 디렉토리등을 설정하기 위한 속성이 있습니다. 여기서는, 프로젝트에 “money”만을 지정해 둡니다.

 

리스트 5.2 project의 설정

<?xml version=”1.0” encoding=”KSC5601”?>

  <project name=”money”>

  </project>

 

여기에서 한번 편집작업을 끝마치고, money디렉토리아래에서 ant명령을 실행해 봅시다. BUILD FAILED가 뜨고, 그림 5-2와 같은 메세지가 표시됩니다. 메세지와 같이. project요소에는default속성이 필수입니다. default에서 지정해야만 하는 타겟트가 존재하지 않기 때문에, 우선default=”main”이라고 속성을 덧붙입니다.(리스트5-3)

 

$ ant

 Buildfile: build.xml

  BUILD FAILED

  /home/kakeda/doc/xunitbook/sample/money/build.xml:2:the default attribute of project is required

  Total time: 2 seconds

그림 5-5 디폴트 타겟트의 실행

 

 

리스트 5-3 default타겟트을 넣은 project의 설정

<?xml version=”1.0” encoding=”KSC5601”?>

  <project name=”money” default=”main”>

  </project>

 

default타겟을 지정한 후에 다시 ant명령을 실행하면, 이번에는 메세지가 변경됩니다. 이 에러는 타겟트가 존재하지 않기 때문에, 우선 무시해도 상관 없습니다.

 

5.3.5 최초의 타겟트

 여기부터 각 타겟트의 작성에 들어 갑니다. 타겟트는, target요서를 사용해서 작성합니다. 우선 시작은, 소스를 빌드하기위해서 필수인 디렉토리를 작성하는 타겟을 만들겠습니다.

 Target요소에는 몇개의 속성이 있습니다만, 적어도 name속성이 있으면 동작합니다. 이 타겟은 빌드를 위해 준비를 행하는것으로써, prepare라는 이름으로 합니다. 타겟트의 내부디렉토리의 작성을 하는 것에는, mkdir태스크을 사용합니다. 태스크란, 타겟트내부에서 지정한 Ant가 제공하는 실행명령과 같은 것입니다.

 Prepare타겟트를 추가한 build.xml은. 리스트5-4와 같이 됩니다. 역시, mkdir태스크 요소의 뒤에 “/”가 붙어 있는 것은 XML요소를 닫는 태그가 필요하기 때문입니다. 타겟트를 추가했기 때문에, project요소의 default속성에는 prepare타겟트를 지정하는 것으로 합니다.

 

리스트 5-4 prepare타겟트를 추가한 project의 설정

<?xml version=”1.0” encoding=”KSC5601”?>

  <project name=”money” default=”prepare”>

    <target name=”prepare”>

      <mkdir dir=”build”>

      <mkdir dir=”dist”>

    </target>

  </project>        

 

이 build.xml에서, ant코맨드의 실행해 봅시다. Default속성에 prepare타겟트를 지정하고 있기 때문에, ant와 실행만으로 prepare타겟을 실행해 줍니다. 당연, ant prepare와 같이 실행할 수 있습니다. Ant코멘드를 실행하면, 그림 5-3과 같은 메세지가 표시됩니다.

 

 

그림 5-3 ant prepare의 실행

$ ant

 Buildfile:build.xml

  Prepare:

 Created dir: /home/kakeda/doc/xunitbook/sample/money/build

 Created dir: /home/kakeda/doc/xunitbook/sample/money/dist

  BUILD SUCCESSFUL

  Total time: 1 second

$ ls –F

build/ build.xml  dist/  src/

 

아무일이 없다면 디렉토리가 작성되었을 것입니다. 이 처럼 필요한 타겟트를 추가해서, (필요에 따라 타겟트를 지정해서)실행해 나갑니다.

 

5.3.6 그 밖에 타겟트

 prepare타겟트가 작성되었습니다. 여기 부터는, 간단한 설명과 함께 다른 타겟트를 추가해보록 하죠. 일반적인 자바소스의 컴파일에 필요하다고 생각되는 타겟트는, 다음 4가지 입니다.

ㄱ.   javac에 따른 컴파일

ㄴ.   컴파일한 클래스파일의 삭제

ㄷ.   빌드용으로 작성한 파일, 디렉토리전부의 삭제

ㄹ.   jar파일의 작성

이것들의 타겟트를 build.xml에 적용하면, 리스트5-5와 같이 됩니다. 역시 각각의 타겟트의 상세한 설명은 다음 절로 뒤로 미루겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

리스트 5-5 타겟트를 추가한 build.xml

<?xml version=”1.0” encoding=”KSC5601”?>

  <project name=”money” default=”compile”>

    <!- -디렉토리의 작성- - >

    <target name=”prepare”>

      <mkdir dir=”build” />

      <mkdir dir=”dist/lib” />

    </target>

    <!- - 컴 파 일 - - >

    <target name=”compile” depends=”prepare”>

      <javac srcdir=”src” destdir=”build”>

        <include name=”**/*.java” />

      </javac>

    </target>

<!- - jar파일의 작성 - - >

    <target name=”jar” depends=”compile”>

      <jar jarfile=”dist/lib/money.jar”

          basedir=”build”

          excludes=”**/*Test*” />

    </target>

<!- - 클래스 파일의 삭제 - - >

    <target name=”clean”>

      <delete>

        <fileset dir=”build”>

          <include name=”**/*.class” />

        </fileset>

      </delete>

    </target>

<!- - 작성한 디렉토리, 파일의 삭제 - - >

    <target name=”distclean”>

      <delete dir=”dist” />

      <delete dir=”build” />

    </target>

  </project>

 

5.4 Ant의 기초

 Ant에는 태스크에 넣는 것이 많습니다만, 본장에서는 이 중에서도 기본적인 태스크와, Ant의 베이스가 되는 기능에 대해서만 설명합니다. 각각의 태스크의 전부의 속성이나, 그 밖의 태스크는,  Ant에 딸린 HTML문서나, 표 5-4의 URL을 참조해 주십시요.

 

표5-4 Ant문서의 URL

URL

설명

http://jakarta.apache.org/ant/manual/

Ant-1.3의 영문판 매뉴얼

http://jakarta.apache-korea.org/

자카르타 한국판 매뉴얼

(현재 미완성이지만 꾸준히 참여 부탁드립니다.)

 

5.4.1 target

 전 절에서 언급했지만, target은Ant에서 정의되는 처리의 단위입니다. ant커맨드의 뒤에 타겟트명을 지정하는것에서, 임의의 타겟트를 실행하는 것을 할 수 있습니다.

 target요소에는, name속성과 다른 몇개의 속성을 저정할수 있습니다. depends속성은, 타겟트간의 의존관계을 설정하기 위해서 사용합니다. 예를 들어, B라는 타겟트의 앞에 반드시 A라는타겟을 실행해 두고 싶은 경우는, 리스트 5-6과 같이 씁니다.

 depends속성은, 복수의 타겟트명을 컴마”,”로 구분해서 지정할 수 있습니다. 예를 들어, C라는 타겟의 앞에 A,B라는 타겟을 실행해 두는 경우는, 리스트 5-7과 같이 지정할 수 있습니다.

 

리스트 5-6 depends 속성의 예 (1)

<target name=”A”> …</target>

<target name=”B” depends=”A”>…</target>

 

리스트 5-7 depends속성의 예 (2)

<target name=”A”>…</target>

<target name=”B”>…</target>

<target name=”C”  depends=”A,B”>…</target>

 

 

 

 

 

5.4.2 fileset

 fileset는, 패턴 매칭에 따라 파일집합을 다루기 위한 요소 입니다. 지정 디렉토리의 이하의 전부에 대해서 패턴 매치하는 파일, 패턴에 매치하지 않는 화일, 또는 그 매치 / 비매치 둘을 만족하는 조건의 파일을 집합으로써 다룹니다.

 예를 들면, build디렉토리이하의 자바 파일을 포함하지만, 테스트 클라스의 파일(Test라는 이름을 붙인)은 제외 하는 경우는, 리스트 5-8과 같이 지정합니다.

 

리스트 5-8 filest의 예

<fileset dir=”build/”>

  <include name=”**/*.java” />

  <exclude name=”**/*Test” />

</fileset>

 

 리스트 5-8에서는, filest요소는 dir속성에서 지정한 디렉토리을 기준으로한 파일 집합을 정의하고 있습니다. fileset요소중에 기술하고 있는, include(처리대상)의 exclude (제외대상)의 두개의 요소 이름에 패턴을 지정해서, 파일 집합을 표시합니다.

 Include와 exclude에서 지정할 수 있는 패턴에는 표 5-5와 같은 종류가 있습니다.

 

표 5-5 fileset에서 지정할 수 있는 패턴

패턴

의미

예

*

0개이상의 문자와 매치

“.java(hoge.java에 매치)

?

1 개이상의 문자와 매치

Test?.java (Test0.java에 매치, Test.java에는 매칭하지 않음)

**

0계층이상의 디렉토리와 매치

src/framework/**/*.class (src/framework/a/a.class에는 매치,

src/hoge/hoge.class에는 매치하지 않음)

 

5.4.3 property 태스크

 프로퍼티는, build.xml중에서 사용할 수 있는 이름과 값을 가진 변수 입니다. build.xml안에서프로퍼티를 설정하는 경우에는, property테스크를 사용합니다. (리스트 5-9) 반대로, 설정한 프로퍼티를 참조하는 것에는, “${“ 와 “}”에 프로퍼티명을 사이에 두어 씁니다.

 

 

 

리스트 5-9 property 태스크의 예

<!- -프로퍼티foo의 설정 - ->

<property name=”foo” value=”var” />

<!- -프로퍼티 foofoo에 프로퍼티 foo의 값을 설정 - ->

<property name=”foofoo” value=”${foo}” />

 

 

또, 설정되어 있는 환경변수를  얻고 싶은 경우에도, property태스크를 사용합니다.

Environment속성에 “프로퍼티명”을 설정하면, 환경변수는 “${프로젝트명.환경변수명}”

이라는 식으로  얻을수 있도록 되어 있습니다. (리스트 5-10)

 

리스트 5-10  property 테스크에서 환경변수를 취득

<!- - MYENV를 prefix에 지정한다 - - >

<property environment=”MYENV.” />

<!- - MYENV.?에서 환경변수를 참조할 수 있다 - - >

<echo>LANGUAGE IS ${MYENV.LANG}</echo>

 

5.4.4 classpath와 path

 classpath는, build.xml의 가운데 클래스의 저정을 한 경우에 설정하는 요소입니다. 각각의 클래스의 속성에 classpath를 지정하는 것도 가능하지만, 일반적으로는 프로젝트 공통의classpath를 한개 설정해 두는 것이 되게 해봅시다.

 classpath의 예1(리스트 5-11)에서는, 환경변수 classpath와 /usr/java/junit.jar를CLASSPATH로써 설정하고 있습니다. 여기서 classpath요소안에 기술되어 있는pathelement는, 패스를 표시하는 특수한 요소입니다. pathelement의 속성에 path와location이라는 각각의 속성이 설정되어 있습니다만, 저마다 용도에따라 가려 쓸 필요가 있습니다.(표 5-6 참조)

 

리스트 5-11 classpath의 예1

<classpath>

  <pathelement path=”${classpath}” />

  <pathelement location=”/usr/java/junit.jar” />

</classpath>

 

표 5-6 pathelement 요소의 속성

속성

의미

path

복수의 패스를 포함하는 때에 지정

location

Jar파일과 같게 단독 패스의 경우에 지정

 

또, classpath의 예2(리스트 5-12)와 같게 path요소를 사용하면, 복수의 pathelement를 포함해서 패스의 집합을 표시하는 것이 가능합니다. 그때,  path요소에 id속성을 설정하는것에 따라식별자를 설정하고, 다른 path요소나 classpath요소로 부터 refid속성을 지정해서 참조하는 것이 가능합니다.

 

리스트 5-12 classpth의 예2

<! - -여기서 classpath에서 사용하는 path요소를 설정 - - >

<path id=”project.class.path”>

  <pathelement path=”${classpath}” />

  <pathelement location=”/usr/java/junit.jar” />

</path>

  <! - -classpath부터 path요소을 id 를 지정해서 참조 - - >

<classpath refid=”project.class.path” />

 

 

5.4.5 mkdir태스크

 mkdir태스크는, 디렉토리를 작성하는 태스크입니다. dir속성에 작성하고 싶은 디렉토리명을 지정합니다. 복수계층의 디렉토리를 지정하는 것도 할 수 있습니다.

 mkdir의 예1(리스트 5-13)에서는, “dist”, 예2 (리스트 5-14)에서는 “src/framework/main” 라고 하는 이름의 디렉토리를 (존재하지 않으면) 작성하고 있습니다.

 

리스트 5-13 mkdir 태스크의 예1

<mkdir dir = “dist” />

 

리스트 5-14 mkdir태스크의 예 2

<mkdir dir = “src/framework/main” />

 

5.4.6 copy태스크

 copy태스크는, 파일및 디렉토리의 카피를 합니다. 또 copy태스크내에 fileset을 포함하는 것도할 수 있습니다. Copy태스크의 예 1 (리스트 5-15)에는, “a.txt”라는 파일을 “b.txt”라는 파일명으로 카피하고 있습니다. 예2 (리스트 5-16)에서는, “src디렉토리이하 전부의 디렉토리안의, 테스트 클래스 (test라는 이름이 붙은)와 백업파일(.bak)를 뺀 java소스”를 카피합니다.

 

리스트 5-15 copy태스크의 예1

 

<copy file=”a.txt” tofile=”b.txt” />

 

리스트 5-16 copu태스크의 예2

 

<copy todir=”build/”>

  <fileset dir=”src”>

    <include name=”**/*.java” />

    <exclude name=”**/*Test*” />

    <exclude name=”**/*.bak” />

  </fileset>

</copy>

 

 

5.4.7 delete 태스크

 delete태스크는, 파일및 디렉토리의 삭제를 행하는 경우에 쓰여집니다. Delete태스크의 예1(리스트 5-17)과 같이 file속성을 지정하면 파일을, dir속성을 지정하면 디렉토리를 삭제합니다. 예2 (리스트 5-18)과 같이, fileset을 지정하는것도 가능합니다. 이 예에서는, 현제 디렉토리이하부터 “백업화일(.bak또는 ~)”을 삭제하고 있습니다.

 

리스트 5-17 delete태스크의 예1

<delete file=”/lib/test.jar”/>

<delete dir=”lib”/>

 

 

 

 

리스트 5-18 delete태스크의 예2

<delete>

  <fileset dir=”.”>

    <include name=”**/*.bak”/>

    <include name=”**/*~”/>

  </fileset>

</delete>

 

 

5.4.8 javac태스크

 javac태스크는, javac명령어와 동등한 기능을 하는 태스크입니다. make로 부터 javac커맨드를 실행하는데 비해,  Ant부터 직접 javac의 기능을 호출하기때문, 커맨드 호출하는 시간의 오버해드와 javaVM의 기동하는 시간이 적어 집니다.

 Javac태스크에는 많은 속성이 설정 가능합니다. 통상적은, javac태스크의 예1(리스트5-19)와같이 해서 사용합니다. 이 예에서는, src디렉토리이하의 소스를 컴파일해서, 클래스파일을build이하에 배치하는 설정으로 되어 있습니다. classpath에는, lib/hoge.jar를 포함하는 것이가능합니다. srcdir속성은 소스파일을 두는 장소를, destdir속성은 컴파일한 클래스를 두는 장소로 지정합니다.

 

리스트 5-19 javac태스크의 예1

<javac srcdir=”src”

       destdir=”build”

       classpath=”lib/hoge.jar”>

</javac>

 

예 1의 classpath속성에 classpath요소를 지정하면, 예2 (리스트 5-20)과 같이 고쳐쓰는 것도가능합니다.

 

 

 

 

 

 

 

리스트 5-20 javac 태스크의 예 2

 

<!- - classpath의 설정 - - >

  <path id=”project.classpath”>

    <pathelement location=”lib/hoge.jar” />

  </path>

  <javac srcdir=”src”

         destdir=”build”>

  <! - - 위에서 설정한 classpath를 참조한다 - - >

    <classpath refid=”project.classpath” />

  </javac>

 

5.4.9 java 태스크

 java태스크는, java코맨드와 동등한 기능을 하는 태스크입니다. 예를 들면, app.jar에 포함되어있는 app.test.Main을 실행하는 경우에는, java 태스크의 예 1(리스트 5-21)과 같게 지정합니다.

 

리스트 5-21 java클래스의 예1

<java classname=”app.test.Main”>

  <classpath>

    <pathelement location=”app.jar” />

    <pathelement path=”${java.class.path}” />

  </classpath>

</java>

 

 시스템프로퍼티를 설정하고 싶은 경우는 sysproperty요소를, 클래스에 대해서 인수를 주고 싶은 경우는 arg요소를 사용해서, 예2 (리스트 5-22)와 같이 지정합니다.

 

리스트 5-23 jar클라스의 예1

 

<jar basedir=”build/classes” jarfile=”lib/app.jar” />

 

 jar에 포함하는 파일과 제외하는 파일을 지정하는 경우에는, 예2 (리스트 5-24)와 같이 jar태스크의 includes또는 excludes속성을 사용하든지, fileset에서 파일 모음을 지정합니다. 이 예에서는, app/test이하전부의 파일에서, “Test.class”이라는 이름을 붙인 파일을 jar파일에 포함시킴니다.

 

리스트 5-24 jar태스크의 예2

 

<jar basedir=”build/classes”

     jarfile=”lib/app.jar”

     includes=”app/test/**”

     excludes=”**/*Test.class” />

 

 

5.4.11 javadoc 태스크

 javadoc태스크는, javadoc커맨드와 같은 기능을 실행하는 태스크입니다. Javadoc태스크는, javac태스크나 java태스크와 같이 Ant로 부터 직접기능을 불러드리는 것이 아니고, javadoc커맨드를 java로 부터 실행합니다. 직접호출이 아니기 때문에, 다른 태스크보다도 커맨드 실행시간에 오버해드가 걸립니다.

 

리스트 5-25 javadoc태스크의 예

 

<javadoc packagenames=”app.test.Main”

             sourcepath=”src”

             destdir=”docs/api”

             author=”true”

             version=”true”

             use=”true”

             windowtitle=”Test API”

             doctitle=”<h1>test Main</h1>”

             bottom=”<i></i>”>

  <link offline=”true”

             href=http://java.sun.com/products/jdk/1.3/docs/api/

             packagelistLoc=”/tmp”/>

  <link href=”http://developer.java.sun.com/developer/

             products/xml/docs/api/”/>

</javadoc>

 

 

 

5.4.12 그 밖에 들어가는 태스크

 그 밖에 들어가는 태그에 대하여는, 표 5-7의 기능일람을 참조해 주십시요.

 

표 5-7 그 밖의 태스크 기능 일람

 

태스크명

기능개요

Ant

다른 build.xml을 실행한다.

AntCall

같은 build.xml의 타겟을 호출해 실행한다.

AntStructure

build.xml의 DTD를 출력한다.

Apply

인수를 수반하는 외부 커맨드를 실행한다.(파일지정 두개)

Available

각종조건을 첵크하고 변수를 정의한다.

Chmod

파일의 퍼미션을 변경한다.(Unix경우)

Cvs

cvs커맨드를 실행한다.(다음절에 설명한다.)

Echo

지정한 문자열을 표시한다.

Exec

인수를 수반하지 않는 외부 커맨드를 실행한다.

ExecOn

인수를 수반하는 외부 커맨드를 실행한다.(피일지정 한개)

Fail

현재의 빌드를 실패해서 종료한다.

Filter

파일 필터를 설정한다.

FixCRLF

개행코드를 로컬환경에 맞게 변환한다.

GenKey

키 생성을 한다.

Get

지정한 URL로 부터 파일을 취득한다.

GUnzip

gzip파일을 전개한다.

Gzip

gzip파일을 작성한다.

Mail

SMTP에서 메일을 보낸다.

Move

파일을 이동한다.

Patch

패치를 적용한다.

Property

프로퍼티를 설정한다.

Replace

파일안의 문자열을 치환한다.

Rmic

RMIC커맨드를 실행한다.

SignJar

Jar파일에 사인을 한다.

Sql

SQL을 실행한다.

Style

XML에 스타일 파일을 적용한다.

Tar

tar 압축화일을 작성한다.

Taskdef

자기가 만든 클래스를 설정한다.

Touch

파일의 일부를 편경, 그렇지않으면 신규작성한다.

Tstamp

타임 스탬프를 설정한다.(변수로 부터 참조가능)

Unjar

Jar파일의 압축을 푼다.

Untar

tar파일의 압축을 푼다.

Unwar

war파일의 압축을 푼다.

Unzip

zip파일의 압축을 푼다.

Uptodate

저정한 파일이 변경되어 지고 있다면 프로퍼티를 설정한다.

War

War파읿을 작성한다.

Zip

zip파일을 작성한다.

 

5.4.13 ant커맨드에 대해서

 

 Ant를 실행하기 위한 커맨드에 관해서는, ant(쉘 스크립트), ant.bat(DOS배치파일), runant.pl(perl스크립트)가 있습니다. ant, ant.bat에 대해서는, -help옵션에서 커맨드옵션의 사용법이 표시되어 있습니다. (그림 5-4). 각각의 구체적인 내용에 대해서는, 핼프 메세지를 참조해 주십시요.

$ant -help

ant [options] [target [target2 [target3] ...]]

Options:

  -help                  print this message

  -projecthelp           print project help information

  -version               print the version information and exit

  -quiet                 be extra quiet

  -verbose               be extra verbose

  -debug                 print debugging information

  -emacs                 produce logging information without adornments

  -logfile <file>        use given file for log

  -logger <classname>    the class which is to perform logging

  -listener <classname>  add an instance of class as a project listener

  -buildfile <file>      use given buildfile

  -D<property>=<value>   use value for given property

  -find <file>           search for buildfile towards the root of the

                         filesystem and use it

 

그림 5-4 ant의 헬프 메세지

5.5 자동빌드와 테스트

 이번 절에서는, 제목의 Ant+JUnit+CVS에 따른 자동빌드와 태스트에 대해 설명합니다. 우선 구축순서을 말한 후, 각각의 태스크의 설명을 간단하게 해서, 실제의 프로젝트에의 적용에 대해 설명합니다.

 

5.5.1 Ant, JUnit, CVS

 Ant에서는, 옵션태스크에서 JUnit에 관계하는 태스크가 준비되어 있습니다. Ant를 인스콜하는때에 JUnit가 로드 되고 있으면, 그것들의 태스크를 사용할수 있게 됩니다.(jar파일을 다운로드한 장소는 처음부터 포합되어 있습니다.)

 CVS는, 공유형 소스파일판 관리 시스템입니다. CVS를 이용하는 것에 따라, 파일의 변경이력이나, 버젼의 차이등을 항상 첵크 할 수 있습니다. 더욱이, 원격지의 개발자끼리 소스파일의 공유나, 변경점의 머지(merge)등의 실현이 가능합니다. 오픈소스의 개발에서는 표준적으로 이용되고 있고, CVS자체도 오픈소스로 개발되고 있습니다. Ant에서의 CVS에 관계하는 태스크가 표준으로 준비되어 있기 때문에, CVS를 바로라도 사용할 수 있습니다.

 그렇다면, 이것들 Ant, JUnit, CVS를 합쳐서 자동화 빌드의 테스트 환경을 구축해 봅시다.

 

5.5.2 자동빌드와 테스트 환경의 구축순서

 Ant, JUnit, CVS를 합친 자동화빌드와 테스트 환경은, 다음 순서대로 구축할 수 있습니다.

1.       일정시간의 것을 CVS로 프로젝트를 최신 상태로 합니다.

2.       불필요한 파일을 삭제하고, 소스파일의 컴파일을 실행합니다.

3.       생성된 클래스에 대하서, JUnit로 작성한 테스트로 실행합니다.

4.       JUnit의 테스트 결과를 파일에 출력해서, HTML에 변환해서 웹에서 공개합니다.

 Ant의 태스크를 합칠려는 것에 따라, CVS로 부터 업데이트한 최신의 소스파일을 빌드하고, JUnit에 따른 유니트 테스트를 실행합니다. 그리고, 그 소스결과를 HTML에 출력 할 수 있습니다. 필요한 태스크의 설명을 하면서, 자동 빌드의 테스트환경

(=계속되는 통합환경)을 구축해 갑니다. 여기서도, 앞의 소개한 Ant의 샘플에 있는 money프로젝트를 사용해서 설명해 갑니다.

 

CVS태스크

 우선, 자동적으로 CVS로 부터 소스파일을 업데이트하기 위해, CVS커맨드를  시작하는 타겟을작성합니다. 여기서는, 이미 CVS서버의 저장소에 소스파일이 등록되어있는 것을 전제로 한다.

 CVS태스크에는 필수속성이 없습니다. 단순히 CVS커맨드를 실행하고 싶은 경우는, CVS태스크의 예 1(리스트 5-26)과 같이 지정합니다.

 

리스트 5-26 CVS의 예 1

<cvs command=”update –A –d” >

 

CVS는, 통상 저장소라는 소스파일을 보존하는 장소와, 모듈이라고 부르는 프로젝트명을 지정합니다. 그 경우는, 예 2 (리스트 5-27)과 같이 지정합니다. cvsRoot속성이 저장소일 경우, package속성에 모듈명을 지정합니다. 이 예에서 cvs커멘드는 지정하고 있지 않기 때문에, 디폴트의 csv checkout커맨드가 실행됩니다.

 

리스트 5-27 CVS태스크의 예2

<cvs cvsRoot=”/var/lib/cvs” package=”money” />

 

JUnit 태스크

 오픈태스크에 포함된 JUnit태스크는, Ant부터 직접 테스트 케이스를 실행하기 위한 태스크입니다. 직접테스트케이스를 지정해서 실행하는 것은, JUnit의 예 1(리스트 5-28)과 같이 설정합니다. 또, JUnit태스크에서도, 예2 (리스트 5-29)와 같이 fileset에서 실행하는 테스트 케이스를 지정하는 것도 가능합니다. 이 경우, test요소가 아닌, batchtest요소를 사용합니다.

 JUnit태스크안의 formatter요소는, 테스트 결과의 출력형식을 지정합니다. 예1에서는, 플레인텍스트(plain-text)출력을 지정하고 있습니다. 프레인 텍스트형식은 가독성(읽을수 있는 능력)이 높게 됩니다. 그러나 다음에 써있는 JUnitRepot 태스크를 사용해서 텍스트 레포트를 출력하는 경우는, 예2와 같이 XML에서의 출력을 지정합니다. 예2 의 printsummary속성은, JUnit의테스트 결과의 요약화면을 출력하기위해서 설정합니다. printsummary속성은 디폴트에서는no이기때문에, 테스트완료후도 화면에서는 아무것도 표시되지 않습니다. 예2에서는, 요약을 표시하기위해서 합니다.

 테스트 레포트의 출력쪽의 디폴트 값은 현재 디렉토리입니다만, test또는 batchtest요소의todir속성에 이용하는 디렉토리를 설정하는것으로 지정가능합니다.

 

 

 

 

리스트 5-28 JUnit태스트의 예1

 

<junit>

  <formatter type=”plain” />

  <test name=”junit.samples.money.MoneyTest” todir=”report” />

</junit>

 

리스트 5-29 JUnit태스크의 예2

<junit printsummary=”yes” >

  <formatter type=”xml” />

  <batchtest todir=”report”>

    <fileset dir=”build”>

      <include name=”**/*Test.class” />

    </fileset>

  </batchtest>

</junit>

 

JUnitReport 태스크

 JUnit태스크의 테스트결과를 XML로 출력시키는 경우만, JUnitReport태스크에서 테스트 결과를 HTML에 출력하는것이 가능합니다. 원래, UnitTest는 100%패스할 필요가 있기 때문에, 테스트 결과를 출력하는것이 의미가 없다고 생각됩니다. 그러나, degrade를 초기에 발견하고, 특정의 빌드환경에 존재하지 않는 테스트 케이스를 확인 하는 의미라도, 자동테스트는 대단한 의미가 있습니다.

 JUnit에서 출력한 테스트 리포트가 들어갈 곳을 fileset에서 지정해서, XML에 출력된 테스트 레포트를 XSLT에서 HTML으로 변환할 수 있습니다. JUnit태스크에 따라 테스트 레포트를 출력 파일명은, 특히 지정하지 않으면, “TEST-[테스트명].xml”라고 되기 때문에, fileset에서의“TEST-*.xml”로 지정합니다.

 JunitReport태스크안의 report요소에서 생성하는 HTML의 포맷과, HTML이 출력되는 곳을 지정하는 것이 가능 합니다. 포맷은, frames (프레임을 사용한다:그림 5-5)든지 noframes(프레임을 사용하지 않는다:그림 5-6)을 선택하는 것이 가능합니다.

 

 

 

 

 

리스트 5-30 JUnitReport의 예

<junitreport>

  <fileset dir=”report”>

    <include name=”TEST-*.xml”　/>

  </fileset>

  <report format=”frames” todir=”report/html” />

</junitreport>

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Money 프로젝트의 적용

 CVS, JUnit, JUnitReport를, 먼저의 Money프로젝트에 적용해 봅시다. 여기에서는, CVS저장소는 로컬에 있는것을 전제로 합니다. CVS, JUnit, JUnitReport에 관한 타겟에 대하서 번호를 매겨두기 때문에, 이 번호를 참조하면서 설명합니다.(리스트 5-31)

①     은, CVS에서 프로젝트를 최신으로 하는 타겟입니다. Update타겟트의 가운데에서는, CVS태스크에서 update커멘드를 지정하고 있습니다. 이 타겟트에서는 의존관계을 지정하고 있지 않습니다만, distclean에서 전부 클래스 파일을 반드시 삭제하기 때문에, update한다하더라도 괜찮습니다. cvs코맨드의 “update –A –d”라는 옵션은, “태그를 지정시키지 않고, 최신의 소스와 디렉토리를 얻는다”라는 의미 입니다.

②     는, 테스토의 실행을 행하는 타겟트입니다. Test타겟의 안에서는, JUnit태스크에서 테스트케이스를 실행합니다. 의존관계를 update와 compile이 지정되있기 때문에, 반드시 CVS에서 최신의 상태로 변경시킨 후에, 소스를 컴파일해서, 테스트를 실행합니다. 테스트결과의 출력형식은 XML에 지정해서, build디렉토리이하의 “-Test.class”이라는 클래스를 대상으로해서 테스트를 실행하고, 결과를 report디렉토리에 출력합니다.

③     은, 테스트리포트의 HTML출력을 행하는 타겟트입니다. 의존관계에 test타겟을 지정하고 있기 때문에, 반드시 테스트를 실행하기 때문에, 그 결과를 원래의 HTML을 생성합니다. 대상의 파일은, report디렉토리이하의 “TEST-….xml”이라는 파일입니다. 생성한 HTML파일은, 프레임있는 설정에서 report/html이하에 출력합니다.

 

리스트 5-31 CVS, JUnit관련의 타겟을 추가한 build.xml

<?xml version="1.0" encoding="KSC5601" ?>

  <project name="money" default="compile">

    <!-- SET Class pass -->

    <path id="project.classpath">

      <pathelement path="${classpath}" />

      <pathelement location="build" />

    </path>

    <!-- Create directory -->

    <target name="prepare">

      <mkdir dir="build" />

      <mkdir dir="dist/lib" />

      <mkdir dir="report/html" />

    </target>

    <!-- compile -->

    <target name="compile" depends="prepare">

      <javac srcdir="src" destdir="build">

        <include name="**/*.java" />

      </javac>

    </target>

    <!-- 1 report CVS -->

    <target name="update">

      <cvs command="update -A -d" />

    </target>

    <!-- 2 run test -->

    <target name="test" depends="update,compile">

      <junit printsummary="yes">

        <classpath refid="project.classpath" />

        <formatter type="xml" />

        <batchtest todir="report">

          <fileset dir="build">

            <include name="**/*Test.class" />

          </fileset>

        </batchtest>

      </junit>

    </target>

    <!-- 3 create TestReport -->

    <target name="report" depends="test">

      <junitreport>

        <fileset dir="report">

          <include name="TEST-*.xml" />

        </fileset>

      </junitreport>

    </target>

    <!-- create jar file -->

    <target name="jar" depends="compile">

      <jar jarfile="dist/lib/money.jar"

           basedir="build"

           excludes="**/*Test*" />

    </target>

    <!-- delete class file -->

    <target name="clean">

      <delete>

        <fileset dir="build">

          <include name="**/*.class" />

        </fileset>

      </delete>

    </target>

    <!-- delete created directory, file -->

    <target name="distclean">

      <delete dir="dist" />

      <delete dir="report" />

      <delete dir="build" />

    </target>

  </project>

 

5.5.3 cron을 사용한 자동처리

 테스트와 CVS의 업데이트의 자동화는, 주로 스케줄러에서 합니다. UNIX계의 OS라면 cron커멘드에서, Windows2000이라면 태스크에서 1일 수회 스케줄러의 설정이 가능합니다. 여기서는, cron커멘드에서 1일 수회의 자동실행을 스케줄러하는 예를 소개합니다. 또, Windows NT에 표준의 AT커멘드에서는 일단위의 스케줄러만 설정이 가능합니다.

 

스케줄러용 쉘 스크립트

 우선 처음에, cron을 실행하기위해서 쉘스크립트를 작성합니다. 쉘스크립트의 내용은 아래와같습니다.

1.       환경변수의 설정 (JAVA_HOME, ANT_HOME, PATH, CLASSPATH)

2.       ant커멘드의 실행

 예를들면, “distclean후에 report출력을 행함”라고 말한 내용의 쉘스크립트을 작성합니다. Ant의 실행시의 로그는 리다이엑션(redirection)을 사용하지 않고, ant커멘드의 옵션 –logfile을사용합니다.

 

#!/bin/sh

  # set envirment

 JAVA_HOME=/usr/lib/j2sdk1.3; export JAVA_HOME

 ANT_HOME=/usr/local/share/ant; exprot ANT_HOME

PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin; export PATH

 # set project directory

PROJECTDIR=/home/project/money

 # move project directory

cd $PROJECTDIR

 # run ant command

ant –logfile ant.log distclean report

 

그림 5-7 스케줄러용 쉘스크립트

 

crontab에 추가

 다음에, crontab커멘드를 사용해서 아까 작성한 쉘스크립크를 스케줄러링(scheduling)

합니다. 자동실행되게 하고 싶은 유저에서 로그인한 후, “crontab –e”라고 커멘드를 실행하면, cron의 스케줄러 파일을 편집할 수 있습니다. Cron에 관해서의 상세적인 설명은 뒤루 미루고,여기에서는 매일 3회(12, 15, 18시)의 실행을 등록합니다.

0 12,15,18 * * * /user/local/bin/antrun.sh> /dev/nul 2>&1

 

그림 5-8 crontab에 추가한 행

 

 추가한 후의 cron을 재시작하면, 매일3회, 자동빌드와 테스트가 실행됩니다. 테스트 결과는JUnitReport에 따라HTML에 출력될 수 있기때문에, Web을 시작해두고, JUnitReport의HTML출력할 곳의 디렉토리를 Web에서 표시할 수 있도록 설정해두는 쪽이 편리합니다.

 또, mail태스크를 사용해서 실행시의 로그(-logfile에서 지정한 파일)을 개발대상 메일링리스트에 보내도록 설정해서 두면 확인결과를 알 수 있습니다.

 

리소스의 점유율

 ant의 자동실행을 시키는 머신과, 개발자가 각각에 빌드와 테스트를 행하는 머신이 같은 경우,데이타베이스나 메모리, CPU등의 리소스 점유율의 측정을 해 두는 편이 좋습니다.

 필자가 일하고 있는 프로젝트에서, 자동실행시키는 머신과, 각각의 개발자가 개발하는 머신이같았던 경우, 자동으로 전부 테스트케이스를 실행하는 중에, 다른 개발자용 리소스가 압박됬던경험이 있습니다.

 

 

5.6 마치며

 Ant와 CVS, 그리고 JUnit를 합친 것에 따라, 계속된 통합의 필요한, 자동화되는 환경의 구축을설명해 왔습니다. 단독으로써의 make커맨드의 대체로써만이 아니라, 이번 소개할 수 없었던 각각의 태스크를 합쳐서(필요하다면 자기가 만든 테스크를 사용해서)멀티플랫폼에서 이용 할 수있는 Java개발환경을 구해 보십시요.