배포 형식이 EJB JAR 파일, WAR 파일, EAR 파일 중 어떤 것이건 관계없이 특정 디렉토리에 배포 설명자를 배치해야 합니다. 올바른 클래스를 올바른 디렉토리에 포함시켜야 합니다. 공용 클래스를 변경한 경우에는 전체 애플리케이션을 다시 배포해야 할 수도 있습니다. 빌드 과정에서 실수가 생기면 디버깅에 여러 시간이 걸릴 수도 있습니다.
독점(proprietary) IDE를 사용하면 단일 개발자를 위한 빌드 과정을 자동화할 수는 있지만 다른 사람의 작업 결과를 배포하기에는 어려움이 많을 수 있습니다. 시중에는 WLS 애플리케이션을 자동으로 빌드 및 배포할 수 있는 여러 가지 Java IDE가 판매되고 있습니다. 이들 도구는 대개 빌드 및 배포 정보를 독점(proprietary) 포맷으로 저장합니다.
이 정보를 저장하여 다른 개발자에게 전송할 수는 있지만 여러 가지 문제가 발생할 수 있습니다. 첫째, 모든 개발자가 동일한 도구로 작업해야 합니다. 둘째, 일부 도구는 모든 배포 정보를 단일 파일에 저장하므로 단일 복사본으로 동기화하기가 어렵습니다. 셋째, 이러한 도구들은 대개 고도의 유연성을 지원하지 않으므로 다른 서버에 배포하거나, 여러 컴포넌트를 배포하거나, 여러 배포 옵션 중에서 선택하거나, IDE를 사용하지 않고 컴포넌트를 배포하는 일이 쉽지 않습니다.
빌드 도구
Ant는 Java 전용 빌드 도구입니다. 오랫동안 사용되어 온 빌드 도구 또는 make 도구는 애플리케이션의 빌드 과정을 자동화하는 데 사용됩니다. 이들 도구는 일반적으로 컴파일러를 실행하고, 파일 시스템에 대한 액세스를 제공하며, 애플리케이션 빌드와 관련된 다양한 작업을 처리합니다. 또한 운영 체제에 크게 의존하는 경우가 많으며, 일반적으로 편집하기는 어렵고 실수하기는 쉬운 독점 파일 포맷을 사용합니다. 대부분의 make/빌드 도구는 Java 애플리케이션 빌드 기능을 제공할 뿐, 운영 체제 독립성을 제공하지도 않고 Java와 밀접하게 통합되지도 않습니다.
왜 Ant인가?
Ant는 Apache의 Jakarta Project의 일부로 만들어진 이후 java, javac, JAR, WAR 등 여러 Java 작업 기능을 통합해 왔습니다. 또한 많은 파일 시스템 작업을 지원함으로써 운영 체제 독립성을 제공합니다. Windows에서 작성한 스크립트가 Solaris에서도 동일하게 작동합니다. Ant에 없는 것이 있다면 Java를 사용하여 기능을 확장할 수 있습니다. Ant는 확장 가능하므로 WLS를 비롯한 거의 모든 것과 통합됩니다. 이 문서에서는 Ant를 통합하여 WLS 애플리케이션의 빌드 및 배포 프로세스를 자동화하는 방법을 소개합니다. 여러 가지 방법이 있을 수 있으므로 어느 하나가 최고라고 말할 수는 없습니다. 훌륭한 코드와 마찬가지로 Ant 스크립트 작성도 리팩토링을 요하는 반복적인 과정입니다. 여기서는 Ant를 사용하여 WLS 애플리케이션을 빌드 및 배포하는 데 초점을 맞추겠습니다. Ant에 대한 일반적인 정보는 http://jakarta.apache.org/ant를 참조하십시오.
Ant는 Java IDE를 대신하지 않습니다. 개발자는 편리한 도구를 사용하여 코드를 개발하고 배포 설명자를 작성할 수 있지만, 프로젝트 빌드에 통합하기 위한 컴포넌트가 준비되면 Ant build.xml 스크립트를 포함해야 합니다. build.xml 파일은 애플리케이션 또는 컴포넌트의 빌드 및 배포 프로세스를 설명하는 XML 파일입니다.
Ant를 사용하더라도 모든 구성을 직접 해야 하지만, 그 이후의 과정은 Ant가 자동화합니다. Ant를 사용하면 패키지, 빌드 및 배포 프로세스를 XML 형식으로 정의할 수 있습니다. XML은 살아있는 문서이므로 모든 팀 구성원이 XML Ant 스크립트를 읽고 수정하는 것은 물론 실행도 할 수 있습니다. 또한 XML 빌드 스크립트를 업데이트하여 프로세스를 다듬을 수도 있습니다. Ant를 사용하면 복잡하고 지루한 연산을 실수 없이 신속하게 실행할 수 있습니다.
Ant를 시작하는 방법
시작하기 전에 환경을 설정해야 하지만 WLS에서는 이것이 쉽지 않습니다. WLS 6.1부터 Ant가 weblogic.jar에 포함되어 제공되므로, 이제 Ant 빌드 스크립트는 예제 코드와 함께 WLS에 포함됩니다. BEA 제품을 설치하면 Ant bat 및 shell 스크립트가 WLS bin 디렉토리에 저장됩니다. 다시 말해서 WLS 6.1을 설치하면 Ant도 설치됩니다. WebLogic Server의 이전 버전을 사용하는 경우에는 http://jakarta.apache.org/ant/manual/install.html에서 Ant를 다운로드해야 합니다. 최신 버전을 다운로드하여 압축을 풀기만 하면 됩니다. Ant 배치 및 스크립트 파일은 bin 디렉토리에 포함되어 있습니다.
예제 애플리케이션에 대한 설명부터 시작하겠습니다. 애플리케이션에는 EJBOne과 EJBTwo라는 두 개의 EJB가 포함됩니다. EJBOne과 그 헬퍼 클래스는 mypackage.ejbone 패키지에 있고, EJBTwo와 그 헬퍼 클래스는 mypackage.ejbtwo 패키지에 있습니다. 애플리케이션에는 서블릿과 JSP도 포함됩니다. 서블릿 및 JSP 헬퍼 클래스는 mypackage.client 패키지에 상주하게 되고, JSP는 content라는 디렉토리에 HTML 및 이미지 리소스와 함께 상주하게 됩니다. 다음은 예제 애플리케이션 디렉토리 구조의 레이아웃을 자세하게 보여줍니다.
project/src/content
project/scr/mypackage/client
project/scr/mypackage/common
project/src/mypackage/ejbone
project/src/mypackage/ejbone/notneeded
project/src/mypackage/ejbone/META-INF
project/src/mypackage/ejbtwo
project/src/mypackage/ejbtwo/META-INF
project/src/ear/META-INF
project/staging
project/build
|
Ant를 WLS와 함께 사용
프로젝트 속성
꼭 필요한 것은 아니지만, 우선 속성 파일을 정의하는 것부터 시작하겠습니다. 속성 파일은 특정 프로젝트 내에서 서로 개발 환경이 다르면 변경될 수도 있는 정보를 포함합니다. 다음은 속성 파일의 예제입니다. 파일 이름은 무엇이든 상관없지만 이 예제에서는 config.properties라고 하겠습니다.
WL_HOME=c:/bea/wlserver6.1
STAGING=c:/project/staging
BUILD=c:/project/build
SOURCE=c:/project/src
DEVELOPMENTSERVER= http://localhost:7001
TESTERVER=http://testserver:80
|
파일의 첫 번째 속성은 WL_HOME입니다. WL_HOME은 여러 가지 이유에서 중요한데, 우선 각 개발 환경에서 서로 다른 위치에 WLS을 설치하게 되며, 새로운 WLS 버전으로 마이그레이션할 때 빌드 과정에서 사용할 WLS 버전을 제어할 수 있습니다. 다음 속성은 STAGING으로 여기에는 모든 컴포넌트(예: JAR, EAR, WAR)를 배포하기 전에 저장해 두는 위치가 포함됩니다. BUILD는 컴파일한 파일 및 임시 파일을 모두 저장하는 데 사용됩니다.
DEVELOPMENTSERVER 및 TESTSERVER는 서로 다른 서버의 URL을 정의합니다. 이 정보를 각 build.xml 파일에 저장할 수 있지만 이를 변경하는 일은 매우 지루한 작업이 될 수 있고, 속성 파일의 유연성도 제공되지 않습니다. 각 개발자는 사용자 정의 속성 파일을 사용할 수 있습니다. 서로 다른 개발 서버를 사용하거나 서로 다른 운영 체제를 사용할 수도 있습니다. 또한 정보는 ant.bat 또는 ant.sh 파일에 저장할 수도 있습니다.
각 개발자는 복사본을 만들어 보관할 수는 있지만 각 애플리케이션에 대해 사용자 정의할 수는 없습니다. 명령줄에서도 값을 지정할 수 있지만 아주 약간의 입력만 가능합니다. 속성 파일의 기본적인 역할은 개발 환경의 차이 및 애플리케이션 환경의 차이에 따라 사용자 지정이 가능하도록 하는 것입니다.
컴포넌트 빌드
다음 단계는 컴포넌트 빌드를 시작하는 것입니다. EJBOne을 위한 JAR 파일을 빌드하는 것으로 시작하겠습니다. 이 예제의 첫 번째 행은 스크립트에 대한 기본 정보를 정의합니다.
<project name="EJBOne" default="deploy" basedir=".">
<property file="../../config.properties"/>
|
기본 대상은 명령줄에 지정되어 있지 않은 경우에 실행될 대상입니다. 대상에 대해서는 뒤에서 자세히 설명하겠습니다. basedir은 모든 명령이 실행되는 디렉토리를 정의합니다. 이 경우에는 XML 빌드 스크립트를 기본 디렉토리에 배치했습니다. 이렇게 하면 각 컴포넌트가 자체의 빌드 스크립트를 갖게 되기 때문에 편리합니다. 컴포넌트의 소스 코드와 함께 버전 제어에 대해 빌드 스크립트를 확인합니다. 모든 개발자가 컴포넌트 소스 코드를 사용하여 Ant 스크립트를 실행하고 컴포넌트를 빌드 및 배포할 수 있습니다. 다음 행에는 Listing 1에서 정의한 속성 파일이 포함되어 있는데, 이들 속성 대부분을 예제 전체에서 사용하게 될 것입니다.
Listing 1
<project name="War File" default="war" basedir=".">
<property file="../../config.properties"/>
<target name="update_war" depends="compile_war,war">
<java classname="weblogic.deploy" fork="yes"
failonerror="yes">
<sysproperty key="weblogic.home"
value="${WL_HOME}"/>
<arg line="-url ${DEVELOPMENTSERVER} update
mypassword war ${STAGING}/war.war"/>
<classpath>
<pathelement path="${WL_HOME}/lib/
weblogic.jar"/>
</classpath>
</java>
</target>
<target name="compile_war">
<mkdir dir="${BUILD}/war"/>
<javac srcdir="${SOURCE}" deprecation="on"
destdir="${BUILD}/war"
includes= "mypackage/client/**,
mypackage/common/**">
</javac>
</target>
<target name="war" depends="compile_war">
<war warfile="${STAGING}/persdemo.war"
webxml="${SOURCE}/mypackage/client/
web-inf/web.xml">
<webinf dir="${SOURCE}/mypackage/client/
web-inf/">
<patternset id="wls" >
<include name="weblogic.xml"/>
</patternset>
</webinf>
<classes dir="${BUILD}/war"/>
<fileset dir="../../content/"/>
</war>
</target>
</project>
|
컴파일
대상(target)은 작업 단위를 정의합니다. 이것은 명령줄에서 지정할 수도 있고 다른 대상의 종속 항목으로 정의할 수도 있습니다. 다음은 compile_ejbone 대상을 정의하는 코드입니다.
<target name="compile_ejbone">
<mkdir dir="${BUILD}/ejbone"/>
<mkdir dir="${BUILD}/ejbone/META-INF"/>
<javac srcdir="${SOURCE}" destdir="${BUILD}/ejbone"
excludes="mypackage/client/**"
includes= "mypackage/common/**,
mypackage/ejbone">
<classpath>
<pathelement path="${WL_HOME}/lib/weblogic.jar"/>
</classpath>
</javac>
<copy todir="${BUILD}/ejbone/META-INF">
<fileset dir="${SOURCE}/mypackage/ejbone/META-INF">
<include name="*.xml"/>
</fileset>
</copy>
</target>
|
컴파일 대상은 EJBOne의 클래스 컴파일을 담당합니다. 먼저 mkdir을 호출하여 필요한 디렉토리를 만듭니다. 운영 체제에 따라 명령이 다르므로 이 스크립트는 어떤 환경에서도 작동해야 한다는 점을 명심하십시오. 디렉토리를 만들었으면 코드를 컴파일할 준비가 된 것입니다.
Ant 작업 javac를 호출하여 javac 컴파일러를 불러옵니다. javac 작업에서는 컴파일할 패키지와 Java 클래스를 선별할 수 있습니다. includes 속성을 지정하지 않으면 소스 디렉토리의 모든 파일이 컴파일됩니다. excludes 속성을 사용하면 특정 Java 파일 및 패키지를 제거할 수 있습니다.
이 경우에는 ExtraClass 클래스와 mypackage/ejbone/notneeded 패키지를 제외하고 mypackage.common 및 mypackage. Ejbone 패키지의 모든 클래스를 컴파일해야 합니다. 올바른 WLS 버전으로 컴파일하려면 클래스 경로를 정의합니다. 마지막으로 배포 설명자를 빌드 디렉토리에 복사하여 모두 JAR 파일이 되도록 할 수 있습니다.
JAR 빌드
다음 단계는 JAR 파일을 EJB용으로 빌드하는 것입니다. 다음은 Ant 코어 작업 JAR을 사용하여 컴파일된 클래스 및 배포 설명자가 포함된 임시 JAR 파일을 빌드하는 코드입니다.
<target name="jar_ejbone" depends="compile_ejbone">
<jar jarfile="${BUILD}/_ejbone.jar"
basedir="${BUILD}/ejbone"/>
</target>
|
jar_ejbone 대상은 compile_ejbone 대상의 종속 항목이므로 클래스를 컴파일해야 JAR 파일을 만들 수 있습니다. jar_ejbone 대상을 호출하면 compile_ejbone 대상이 먼저 호출됩니다. compile_ejbone 대상이 실행되지 않은 경우에는 먼저 이것이 자동으로 실행된 후에 jar_ejbone 대상이 실행됩니다.
EJBC 실행 시 다음 코드의 XML은 ejbc를 Ant와 통합하는 방법을 보여줍니다. 이 대상은 jar_ejbone 및 compile_ejbone라는 두 가지 종속 항목을 포함합니다. jar_ejbone는 compile_ejbone가 실행된 후에야 실행되므로 종속 순서는 중요하지 않으며, jar_ejbone이 두 대상에 대해 종속 항목으로 열거되어 있더라도 두 번 실행되지는 않습니다.
<target name="ejbc_ejbone" depends="jar_ejbone,
compile_ejbone">
<java classname="weblogic.ejbc" fork="yes"
failonerror="yes">
<sysproperty key="weblogic.home"
value="${WL_HOME}"/>
<arg line="-compiler javac ${BUILD}/_ejbone.jar
${STAGING}/ejbone.jar -keepgenerated"/>
<classpath>
<pathelement path="${WL_HOME}/lib/weblogic.jar"/>
</classpath>
</java>
</target>
|
ejbc_ejbone 대상은 java 작업을 호출합니다. 쉽게 알 수 있겠지만, 이 작업은 Java 애플리케이션을 실행하는데 이 경우 Java 애플리케이션은 weblogic.ejbc입니다. Fork는 새 vm을 실행하며 failonerror도 동일한 역할을 수행합니다. ejbc 컴파일 프로세스가 실패하면 빌드도 실패하여 중지됩니다. failonerror 속성은 fork 속성도 yes로 설정된 경우에만 yes로 설정할 수 있습니다. Sysproperty에서는 ejbc에 대한 속성을 지정할 수 있습니다. 그 다음 ejbc에 대한 명령줄 파라미터를 지정하고 마지막으로 클래스 경로를 정의합니다.
배포
EJB JAR 파일을 만들었으면 이제 배포할 수 있습니다. 다음의 update_ejbone 대상은 weblogic.deploy를 실행하는 점을 제외하면 ejbc_ejbone 대상과 거의 동일해 보입니다.
<target name="update_ejbone"
depends="ejbc_ejbone,jar_ejbone,compile_ejbone">
<java classname="weblogic.deploy"
fork="yes" failonerror="yes">
<sysproperty key="weblogic.home"
value="${WL_HOME}"/>
<arg line="-url ${DEVELOPMENTSERVER}
update mypassword ejbone ${STAGING}/ejbone.jar"/>
<classpath>
<pathelement path="${WL_HOME}/lib/weblogic.jar"/>
</classpath>
</java>
</target>
|
weblogic.deploy의 인수 행은 매우 흥미롭습니다. 먼저 config.para-meter 파일의 DEVELOPMENTSERVER 파라미터를 사용하는데 이 파라미터는 배포 URL을 미리 정의된 개발 서버로 설정합니다.
그런 다음 weblogic.deploy가 수행할 동작을 지정합니다. 다음 번 파라미터는 암호인데, 사용자 이름을 지정하지 않았으므로 기본값인 "system"으로 지정됩니다. 시스템 암호를 하드 코드화하는 것이 바람직하지 않으므로 나중에 더 나은 해결책을 찾아보겠습니다.
마지막으로 컴포넌트 이름과 컴포넌트 위치를 지정합니다. 이제 c:\Ant update_ejbone를 입력하면 EJBOne이 컴파일되고 JAR이 지정되며 ejbc가 컴파일되어 개발 서버에 배포됩니다. 컴포넌트는 애플리케이션 디렉토리가 아닌 스테이징 디렉토리로 배포됩니다. 애플리케이션 디렉토리에 동일한 컴포넌트를 설치한 적이 있다면 이를 제거해야 합니다.
또한 이 예제에서는 이미 배포된 컴포넌트를 업데이트하는 방법도 보여줍니다. 새 컴포넌트를 설치하는 대상을 만드는 방법도 이와 매우 유사합니다. 필자는 종종 동일한 컴포넌트를 배포하므로 여기서 업데이트 방법을 보여주었지만, 아주 드물게 전혀 새로운 컴포넌트를 만들기도 합니다.
WAR 빌드
EJB에 대해 살펴보았으므로 이제 WAR 파일을 만들어보겠습니다. Listing 1의 복사 및 컴파일 대상은 WAR 파일을 빌드하는 데 필요한 모든 사항이 build/war 디렉토리에 있는지 확인합니다. Ant에는 war 대상에 사용되는 war이라는 작업이 미리 정의되어 있습니다. jar 작업을 사용할 수도 있지만, war 작업을 사용하면 모든 것이 정확한 디렉토리에 배치되도록 할 수 있습니다. webxml 속성을 사용하여 web.xml 배포 설명자의 위치를 설정하는 방법도 있지만 war 작업은 WebLogic에 대해서만 수행되는 것이 아니므로 weblogic.xml 파일을 수동으로 포함시켜야 합니다. webinf 속성을 사용해서 WAR 파일의 WEB-INF 디렉토리에 속하는 추가 파일을 정의할 수 있습니다. 여기에 weblogic.xml 배포 설명자를 포함한 다음, classes 속성을 설정하여 클래스 위치를 정의합니다. 마지막으로 fileset 속성을 사용하여 HTML, 이미지 및 JSP 파일을 추가합니다.
대용량 애플리케이션을 간단히 배포
모든 컴포넌트를 한 번에 배포해야 하는 상황이라면 build.xml 스크립트를 하나씩 실행하는 것은 지루한 일일 것입니다. 애플리케이션용 Ant 빌드 스크립트를 모두 실행하는 하나의 Ant 빌드 스크립트를 만들 수 있습니다. Listing 2는 마스터 build.xml 스크립트를 보여줍니다. 이 스크립트는 애플리케이션의 모든 스크립트를 관리하는 스크립트입니다. 단독으로는 아무 기능도 못하는 "all"이라는 대상이 정의되었으며 이 대상의 유일한 목적은 종속 항목을 호출하는 것입니다. ejbone, ejbtwo 및 war 대상은 ant 작업을 사용하여 다른 빌드 스크립트를 호출합니다. 따라서 마스터 스크립트에서 프로젝트의 모든 빌드 스크립트를 제어할 수 있습니다. 마스터 빌드 스크립트는 루트 소스 디렉토리에 배치됩니다. 해당 디렉토리에 "ant"를 입력하면 세 컴포넌트가 모두 배포되고 c:\> ant ejbone war를 입력하면 EJBOne 및 WAR 파일만 배포됩니다.
Listing 2
<project name="Master" default="all" basedir=".">
<property file="./config.properties"/>
<target name="all" depends="ejbone,ejbtwo,war"/>
<target name="setup">
<mkdir dir="${BUILD}"/>
<mkdir dir="${STAGING}"/>
</target>
<target name="clean">
<delete>
<fileset dir="." includes="${BUILD}"/>
<fileset dir="." includes="${STAGING}"/>
</delete>
</target>
<target name="ejbone" depends="setup">
<ant antfile="build.xml" dir="${SOURCE}/
mypackage/ejbone/" target="update_ejbone"/>
</target>
<target name="ejbtwo" depends="setup">
<ant antfile="build.xml" dir="${SOURCE}/
mypackage/ejbtwo/" target="update_ejbtwo"/>
</target>
<target name="war" depends="setup">
<ant antfile="build.xml" dir="${SOURCE}/
mypackage/client/" target="update_war"/>
</target>
<target name="ear" depends="setup">
<ant antfile="build.xml" dir="${SOURCE}/
mypackage/ejbone/" target="ejbc_ejbone"/>
<ant antfile="build.xml" dir="${SOURCE}/
mypackage/ejbtwo/" target="ejbc_ejbtwo"/>
<ant antfile="build.xml" dir="${SOURCE}/
mypackage/client/" target="war"/>
<mkdir dir="${BUILD}/ear/"/>
<mkdir dir="${BUILD}/ear/META-INF"/>
<copy todir="${BUILD}/ear" >
<fileset dir="${STAGING}" >
<exclude name="**/*.ear"/>
</fileset>
</copy>
<copy file="${SOURCE}/ear/META-INF/
application.xml" tofile="${BUILD}/ear/META-INF/
application.xml"/>
<jar jarfile="${STAGING}/project.ear" basedir=
"${BUILD}/ear/"/>
<java classname="weblogic.deploy" fork=
"yes" failonerror="yes">
<sysproperty key="weblogic.home" value=
"${WL_HOME}"/>
<arg line="-url ${DEVELOPMENTSERVER} update
${password} projectname ${STAGING}/
project.ear"/>
<classpath>
<pathelement path="${WL_HOME}/lib/
weblogic.jar"/>
</classpath>
</java>
</target>
</project>
|
마스터 빌드 파일의 다음 대상은 "ear"입니다. 이 대상은 EAR 파일을 빌드하여 개발 서버에 배포합니다. 여기서는 대상들을 개별 컴포넌트로서 배포하지 않을 것이므로 다른 build.xml 스크립트를 호출할 때 ejbc 및 war 대상을 지정합니다.
다음으로 application.xml을 META-INF 디렉토리로 복사하고 모든 것을 한꺼번에 EAR에 JAR 파일로 저장합니다. 대상의 다음 단계는 배포입니다. ${password} 파라미터를 추가함으로써 배포가 변경되었습니다. 이제 암호는 더 이상 스크립트에 하드 코드되지 않습니다. 스크립트를 실행할 때 c:\ant ear -Dpassword=yourpasswordhere를 입력하기만 하면 명령줄에서 바로 암호가 전달됩니다.
weblogic.deploy를 호출할 때는 "update"를 사용한다는 점에 유의하십시오. 이것은 이미 배포된 컴포넌트만 업데이트합니다. 새 배포를 위한 대상을 추가할 수도 있고 다른 서버에 배포할 대상을 추가할 수도 있습니다. 심지어는 컴포넌트의 논리 그룹을 배포할 대상을 추가할 수도 있습니다. 마스터 빌드 파일은 뛰어난 유연성을 제공합니다.
결론
Ant를 사용하여 WAR, EJB 및 EAR 파일을 WLS로 빌드 및 배포하는 방법과 마스터 빌드 스크립트를 사용하여 프로젝트를 관리하는 방법을 배웠으므로 마스터 빌드 스크립트가 프로젝트 고유의 요구 사항을 어떻게 충족시키는지 알 수 있을 것입니다. 이것은 Ant를 사용하여 개발 과정을 어떻게 개선할 수 있는지 보여주기 위한 샘플일 뿐입니다.
프로젝트용으로 Ant를 구현할 때는 각 build.xml 파일을 위한 clean 대상을 만들어야 합니다. clean 대상은 build.xml 파일로 생성된 모든 파일을 제거하는 일을 담당합니다. EJB build.xml 파일의 공통 부분을 마스터 빌드 스크립트로 이동할 수 있지만, JAR 파일의 컴파일과 빌드는 각 EJB를 위한 별도의 build.xml에 남겨둘 것을 강력히 권장합니다.
Ant를 버전 제어 시스템과 통합해 보십시오. 반복적인 작업들을 자동화할수록 소프트웨어 개발에 더 많은 시간을 투자할 수 있음을 잊지 마십시오.
Copyright © 2002 SYS-CON Media, Inc.
[출처] Ant를 활용한 애플리케이션 빌드 및 배포|작성자 미소쭌
