2005년 4월 15일 금요일

[펌] 작업에 맞는 툴(Eclipse, JUnit, Ant)

XP를 올바로 구현하는데 도움이 될 최상의 툴 고르기

Level: Introductory

Roy W. Miller
소프트웨어 개발자, RoleModel Software, Inc.
2003년 5월 27일

 

XP를 시도하고 싶어하는 팀은 그 시작점을 모른다. 일반적으로 XP 관행에 대해 많은 질문을 던진다. 이번 주 이론을 실전에 적용하는 방법을 설명한다.

위대한 소프트웨어를 만들기 위해 많은 문서 작성 툴과 디자인 툴이 필요하지 않다. 결과적으로 약간의 비기술적 지원, 두개 정도의 소프트웨어, 몇몇의 헌신된 팀 멤버들이 필요하다. XP는 일을 가능하게 하기 위해 가장 간단한 것을 수행하는 것 그 자체라는 것을 기억하라. 이러한 사실은 디자인, 코드, 프로세스, 툴에 적용된다.

나는 십 년 동안 소프트웨어를 만들고 프로젝트를 관리했다. 그 시가동안 상당히 많은 관리 툴과 코딩 툴을 사용했다. 사람들은 툴에 너무 많이 의존한다. 툴은 저마다의 역할이 있지만 기술과 경력을 대체할 수 있는 것은 없다.

여러분과 여러분이 속한 팀에게 권하고 싶은 것은 비교적 단순한 툴로 시작하라는 것이다. 자바로 작업하고 있다면 다음 툴을 권하고 싶다:

 


 

Eclipse: 팀 친화적인 기본적인 개발 환경

  • 각자 선호하는 소스 코드 제어 툴 (개인적으로, Eclipse 만큼 CVS도 많이 사용했다.)
  • JUnit : 프로그래머 테스트, 커스터머 테스트용 엔진
  • HttpUnit : 웹 애플리케이션 테스트
  • Ant : 매일 애플리케이션을 구현할 경우
  • Shams : 한번도 구현해 본 적 없는 컴포넌트들을 없앨 때, 또는 그러한 컴포넌트들의 존재 여부를 테스트 할때.

이 글에서는 Eclipse, JUnit, Ant를 효과적으로 사용하는 방법에 초점을 맞춘다.

 

Eclipse 시작하기
프로그래머로서 일할 때 여러 IDE를 사용했다. VisualAge for Java (VAJ)를 처음 사용하기 시작했을때 학습곡선은 압도적인 것 처럼 보였다. 하지만 2~3주 지나면서 VAJ 없이 자바 소프트웨어를 작성하는 방법이 궁금해졌다. 이것은 내가 작업해본 중에 가장 놀라운 IDE 였다. Eclipse는 이보다 더 좋다. 게다가 무료이다. 진짜다.

Eclipse는 간단한 전제에 기초한다. 진정으로 통합된 팀 개발 환경이 있어야 한다. 자바로 개발 할 경우 전체 애플리케이션은 자바로 작성된다. 풍부하고 잘 분해된 코드를 보고싶다면 Eclipse용 소스를 보면된다. 이 애플리케이션은 플러그인 아키텍쳐에 기반한, 애플리케이션 구현용 프레임웍이다. Eclipse의 대부분은 플러그인이다. 심지어 자바 개발용 지원까지 플러그인이다. 어떤 것이라도 플러그인 되는 핵심 플랫폼이 있다.

설치는 간단하다. Eclipse 다운로드 페이지에서 미러 사이트를 선택해서 최신의 안정된 구현 또는 최신 배포판을 다운로드 한다. Eclipse가 업그레이드 된 새로운 배포판을 기다릴 필요가 없다. Eclipse 팀내 사람들은 전적으로 테스트 우선주의자들이며 전체 테스트 슈트들을 사용할 수 있다. 따라서 안전한 구현이 어떤 것인지 검토할 수 있다.

일단 배포판을 다운로드 했으면 다음의 설치 및 실행 과정을 완료하라(Windows 사용자 기준):

1.       JDK 1.4 설치.

2.       Eclipse Zip 파일을 C:\eclipse에 풀기.

3.       하드에 C:\EclipseWorkspaces라는 개별 디렉토리 만들기.

4.       시작(Start) 메뉴에 C:\eclipse에서 시작하는 C:\eclipse\eclipse.exe -data C:\EclipseWorkspaces\<your workspace name> 단축아이콘 만들기.

5.       새로운 단축아이콘을 더블 클릭. Eclipse는 C:\EclipseWorkspaces에 작업공간을 위한 하위 디렉토리를 만들 것이다.

Eclipse가 처음 시작할 때 그림 1 같은 것을 볼 수 있다:

그림 1. Eclipse 시작 화면Eclipse Welcome screen

시작 화면은 Eclipse Workspace의 리소스 보기(Resource perspective)의 일부이다. 이것으로 작업공간에 있는 모든 파일 보기가 가능하다. 이 리스트는 왼쪽 상단 코너의 Navigator 뷰에 나타난다. Eclipse는 모두 커스터마이징 할 수 있기 때문에 원하는 곳에 뷰를 옮길 수 있다. 일단 그대로 둔채, Java Browsing 보기로 가보자. Window >Open Perspective를 선택하여 어떤 보기들을 사용할 수 있는지 볼 수 있다. Java Browsing 보기를 선택한다 (그림 2):

그림 2. Java Browsing 보기
Java Browsing perspective

Java Browsing 보기에는 상단에 네 개의 뷰가 있다. 하단에는 에디터가 있다. 네 개의 뷰를 왼쪽 부터 보면 Projects, Packages, Types, Members 순이다. Packages, Types, Members는 모두 자바 구조체들이다. Projects는 자바 패키지용 Eclipse 메타 컨테이너이다. 이 보기는 개발 중 가장 많이 사용하게 될 것이다. 물론 Resource 보기가 소스와 클래스 파일 보다 파일을 다루는데 더 편리하다.

개발을 시작하려면 Sample이라고 하는 자바 프로젝트를 만든다. 다음과 같은 순서이다:

1.       Window >Preferences >Java >New Project 클릭.

2.       Folder 라디오 버튼 클릭한 후 OK 클릭.

3.       File >New >Project 클릭.

4.       Java Project 클릭 후 Next 클릭.

5.       프로젝트 이름에 Sample 입력 후 Finish 클릭.

이제는 Projects 뷰에서 Sample 프로젝트를 봐야한다. 이 부분에서, 툴바에 있는 Create a Java Package 버튼을 클릭하고 com.sample 패키지를 만든다. 그 패키지를 선택한다. 이제 첫 번째 자바 클래스를 만들 준비가 된 것이다. Eclipse가 XP 개발 과정을 어떻게 돕는지 본다.

 

 

JUnit
지난 십 년 동안 나의 소프트웨어 개발 경력에 큰 영향을 끼친 것이 있다면 XP이다. 프로그래머로서 가장 큰 영향력을 갖고 있는 과정은 코드를 작성하기 전에 테스트를 작성하는 것이다. 지난 달에도 언급했지만 테스트를 통과시킬만한 코드를 작성하면 코드가 더 단순해지고 일에 더욱 집중할 수 있다. 지난 달 JUnit을 사용하는 방법을 설명했는데 이번에는 조금 더 자세히 설명하겠다.

JUnit은 Eclipse와 함께 제공되기 때문에 따로 다운로드 할 필요가 없다. Eclipse를 사용하지 않는다면 JUnit (참고자료 참조)을 다운로드 한다. JUnit을 사용하기 위해서는 JUnit JAR를 프로젝트 구현 경로에 놓는다. 그리고 테스트 클래스를 작성한다. 다음 단계는 JUnit을 프로젝트 구현 경로에 넣는 과정이다:

1.       Sample 프로젝트에 마우스를 대고 오른쪽을 클릭하여 컨텍스트 메뉴 맨 밑에 있는 Properties 를 선택한다.

2.       Java Build Path를 선택한다.

3.       Libraries 탭을 선택한다.

4.       Add Variable 버튼을 클릭한다.

5.       New 버튼을 클릭하고 변수 이름에 JUNIT_LIB을 입력한다.

6.       그 변수를 편집하고 C:\eclipse\plugins\org.junit_3.8.1 (JUnit은 Eclipse plug-in이다)에 지정한다.

7.       Sample 프로젝트에 src 폴더를 선택한다.

구현 경로에 JUnit을 넣었다. 외부 JAR를 이 경로에 직접 추가할 수 있었지만 다른 머신의 작업공간을 설정할 때에는 변수를 사용하는 것이 더 쉽다. 다음은 테스트 클래스를 작성하는 과정이다:

1.       툴바의 Create a Java Class 버튼 오른편에 드롭다운 화살표를 클릭하고 Test Case를 선택한다.

2.       테스트 이름으로 TC_Account를 선택한다.

3.       setUp()과 tearDown() 체크 박스를 선택한다.

4.       Finish를 클릭한다.

그림 3 같은 스크린을 보게된다:

그림 3. 테스트 케이스 열기
Open test case

Types 뷰에 TC_Account 클래스 목록을 나열하면 Members 뷰에 그 클래스에 대한 메소드를 볼 수 있다. TC_Account 클래스에 대한 에디터를 열면 생성된 많은 코드와 컴포넌트가 있다.

Account 클래스가 어떤 일을 하는가? 돈을 계좌에 추가할 수 있도록 해보자. 다음과 같은 메소드가 필요하다:

 public void deposit(int amount)

Account에 대한 deposit 메소드를 테스트할 TestCase에 메소드를 추가한다. 테스트 클래스는 다음과 같다:

Listing 1. JUnit 테스트

package com.sample;

import junit.framework.TestCase;

public class TC_Account extends TestCase {

   public TC_Account(String arg0) {
       super(arg0);
   }

   protected void setUp() throws Exception {
      super.setUp();
   }

  public void testDeposit() {
    Account account = new Account();
    assertEquals("Account should start with no funds.", 0, account.balance());
  }

   protected void tearDown() throws Exception {
       super.tearDown();
   }
}

 

account.balance()가 0을 리턴한다는 것을 검사하고 있다. 이 테스트는 컴파일하지 않는다는 것을 주목하라. Account 클래스는 아직 존재하지 않기 때문이다. 그림 4는 테스트가 컴파일 하지 않을 때 작업공간의 모습이다:

그림 4. 컴파일 하지 않는 테스트 케이스
Test case that doesn't compile

스크린 밑에 Tasks 뷰는 컴파일 에러를 보여준다. 에러의 어떤 부분이든 클릭하면 정확한 코드 지점이 나타난다. 사실 Eclipse는 이와같이 소소하지만 편리한 기능이 많다. 예를 들어, 컴파일 문제가 있다는 것을 확인할 방법도 여러가지 이다. Tasks 뷰는 이를 보여주고 에디터는 왼쪽에 빨간 X 원을 갖고 있고 작업공간 상단의 모든 뷰는 빨간색 X를 보여준다. 에디터 왼쪽에 빨간 X 주위를 맴돌면 호버 텍스트에 에러 메시지가 나타난다.

자유롭게 움직이면서 클릭해보면 "숨겨진" 기능도 시험해보라. 각설하고 다시 설명하자면 테스트는 컴파일하지 않는다. 따라서 테스트를 컴파일, 실행, 실패 시킬 충분한 코드를 작성하라. 기억해야 할 것은 우리는 어린아이 걸음마를 하려고 하고 가능한한 모든 것을 단순하게 하려고 한다. com.sample 프로젝트를 선택하여 Account 클래스를 만들면서 툴바의 Create Java Class 버튼을 누르고 클래스 이름으로 Account를 입력하고 Finish를 클릭한다. Account 클래스에 에디터를 열어야 한다. 여기에는 메소드가 전혀 없다. balance() 메소드를 추가한다:

Listing 2. Account 클래스

 

package com.sample; 
public class Account { 
     public int balance() { 
         return 0; 
    } 
}

 

테스트를 실행하려면 TC_Account 타입을 선택하고 툴바의 "달리는 사람" 아이콘 옆에있는 드롭다운 화살표를 클릭하고 Run As >JUnit Test를 선택한다. 테스트는 실행되고 스크린의 밑에 뷰로서 나타난다. 나는 개인적으로 Eclipse가 Fast 뷰 바에 있는 JUnit 뷰를 드롭시킬 수 있도록 할 때까지 작업공간의 왼쪽편으로 이를 드래그하여 JUnit을 Fast 뷰로 만들기를 선호한다. 이 지점에서 Window >Preferences >Java >JUnit을 선택하고 Show the JUnit results view only when a failure or error occurs 체크박스를 체크한다. 에러가 발생하지 않는 한 JUnit Fast 뷰는 안보이게 된다. 모든 것이 잘 진행되면 아이콘의 왼쪽 하단 코너에 녹색 체크를 보게 될 것이다.

테스트를 컴파일 할 정도로 충분한 코드를 만들면 테스트가 통과된다. deposit() 메소드를 누군가 호출한 후에 새로운 밸런스를 테스트하기 위해 테스트 케이스에 또 다른 선언을 추가한다. testDeposit() 메소드는 다음과 같다:

Listing 3. deposit() 메소드용 JUnit 테스트

 

public void testDeposit() {
  Account account = new Account();
  assertEquals("Account should start with no funds.", 0, account.balance());
  account.deposit(5);
  assertEquals("Account should reflect deposit.", 5, account.balance());
}

테스트가 컴파일 할 정도로 충분한 코드를 만들어라. 이 경우 아무것도 수행하지 않는 deposit() 메소드를 Account에 추가한다:

Listing 4. 비어있는 deposit() 메소드가 있는 Account

package com.sample; public class Account { protected int balance; public int balance() { return balance; } public void deposit(int amount) { } }

 

달리는 사람 아이콘을 다시 클릭하여 테스트를 재실행하라. JUnit Fast View는 확장되고 "Account should reflect deposit" 라는 메시지의 오류를 보게된다. 테스트를 실패한 것이다. 테스트가 통과될 수 있는 충분한 코드를 작성하라. deposit() 메소드로 하여금 예금액에 balance를 추가하도록 하는 것으로 충분하다. 테스트를 재실행하면 통과될 것이다.

이와 같이 "테스트를 작성하고 테스트 코드가 통과할 만한 코드를 작성하여 테스트를 실행시키는" 접근방식은 매일 겪게되는 XP 개발 흐름이다. JUnit을 Eclipse와 통합되도록 하려면 당장 코딩하는 것에 집중해야 한다. 테스트 실행은 누워서 떡먹기다. 이를 만드는 것 역시 쉽다. 왜냐하면 Eclipse는 코드를 만드는 작업 과정을 절약시킨다. Account 클래스는 다음과 같다.

Listing 5. 구현된 deposit() 메소드가 있는 Account

 package com.sample;
 
public class Account {
        protected int balance;
        
        public int balance() {
               return balance;
        }
        
        public void deposit(int amount) {
               balance += amount;
        } 
}

 

돈을 예금하도록 하는 것도 좋지만 사람들은 인출도 원할 것이다. Account에 withdraw() 메소드용 테스트를 작성한다:

Listing 6. Account에 테스트 업데이트

 package com.sample;
 
import junit.framework.TestCase;
 
public class TC_Account extends TestCase {
 
        public TC_Account(String arg0) {
               super(arg0);
        }
 
        protected void setUp() throws Exception {
               super.setUp();
        }
        
        public void testDeposit() {
               Account account = new Account();
               assertEquals("Account should start with 
                 no funds.", 0, account.balance());
        
               account.deposit(5);
               assertEquals("Account should reflect 
                 deposit.", 5, account.balance());
        }
 
        public void testWithdraw() {
               Account account = new Account();
               account.balance = 5;
               account.withdraw(3);
               assertEquals("Account should reflect 
                 withdrawal.", 2, account.balance());                
        }
 
        protected void tearDown() throws Exception {
               super.tearDown();
        } 
}

 

아무것도 수행하지 않는 withdraw() 메소드를 Account에 추가하여 테스트가 컴파일하도록 한 다음 테스트를 재실행한다. 이는 실패 할 것이다. 이제 withdraw 메소드를 구현한다. Account 클래스는 다음과 같다:

Listing 7. 구현된 withdraw() 메소드가 있는 Account

package com.sample;
 
public class Account {
        protected int balance;
        
        public int balance() {
               return balance;
        }
        
        public void deposit(int amount) {
               balance += amount;
        }
        
        public void withdraw(int amount) {
               balance -= amount;
        } 
}

 

모든 테스트가 통과될 것이다. 이제 통합할 차례이다. "끊임없는 통합"은 XP에 있어서 매우 중요하다는 것을 기억하는가? 테스트가 통과될 때마다 코드를 시스템에 통합할 수 있다. 일찍 그리고 자주 이를 수행해야 한다. Eclipse는 이것도 쉽다.

통합, 통합, 통합
통합을 위해 Eclipse 작업공간을 준비하는 단계는 다음과 같다. 이 과정중에 CVS를 설정해야한다:

1.       Window >Open Perspective >Other >CVS Repository Exploring을 선택하여 CVS 보기를 연다.

2.       오른쪽 클릭을 하여 New Repository Location을 선택한다. 자신의 특별한 설정에 맞게 모든 매개변수를 입력한 다음 Finish를 클릭한다. CVS Repositories 뷰의 리스트에 리파지토리 위치로 끝나도록 해야한다. 이를 확장하면 HEAD stream, Branches entry, Versions entry도 볼 수 있다. HEAD stream은 사용자들이 통합해야하는 주 코드 스트림이다.

3.       CVS 보기 윈도우를 닫는다.

다음은 코드를 시스템에 통합하는 순서이다:

1.       Sample 프로젝트를 오른쪽 클릭한다.

2.       Team >Share Project를 선택한다. 여러분은 전에 한번도 통합해보지 않은 프로젝트를 공유하고 있다. 보통 이것은 한번에 처리해야한다.

3.       프롬프트가 뜨면, 원하는 리파지토리 위치를 선택하고 Finish를 누른다.

이제 XP 흐름은 다음과 같이 되어가고 있다: "테스트를 작성하고, 테스트가 통과할 수 있는 코드를 작성하고 테스트를 재실행하고 통합한다."

이제 TC_Account를 보자. 코드 중복이 있는지 확인하라. 테스트 메소드들이 Account를 인스턴스화 한다. JUnit 프레임웍은 각 테스트 메소드 전에 setUp() 메소드를 실행한다. 그래서 이것은 모든 테스트가 필요로하는 설정을 수행하는 논리적 장소가 된다. Account 객체를 인스턴스화 하는 것을 평가한다.

이것은 간단한 리팩토링이다. 하지만 Eclipse는 더욱 쉽다:

1.       TC_Account용 에디터로 간다.

2.       testDeposit()에 있는 account 로컬 변수를 오른쪽 클릭한 다음 Refactor >Convert Local Variable to Field를 선택한다.

3.       필드 이름으로 "account"를 입력하고 protected 액세스 한정사를 선택한 다음 OK를 누른다. 이제 테스트 클래스는 account라는 방어 필드를 갖게되었고 테스트 메소드는 이를 초기화한다.

4.       account를 초기화하는 라인을 테스트 메소드에서 setUp()으로 옮긴 다음 다른 테스트 메소드에서 선언과 초기화를 삭제한다. 이제 테스트 클래스는 다음과 같다:

Listing 8. Refactored TC_Account

package com.sample;
 
import junit.framework.TestCase;
 
public class TC_Account extends TestCase {
 
        protected Account account;
 
        public TC_Account(String arg0) {
               super(arg0);
        }
 
        protected void setUp() throws Exception {
               super.setUp();
               account = new Account();
        }
        
        public void testDeposit() {
               assertEquals("Account should start with 
                 no funds.", 0, account.balance());
               
               account.deposit(5);
               assertEquals("Account should reflect 
                 deposit.", 5, account.balance());
        }
        
        public void testWithdraw() {
               account.balance = 5;
               account.withdraw(3);
               assertEquals("Account should reflect 
                 withdrawal.", 2, account.balance());                
        }
 
        protected void tearDown() throws Exception {
               super.tearDown();
        } 
}

 

여전히 할 일이 남아있지만 Eclipse는 적어도 단순한 코딩작업 정도는 안해도 된다. 콘텍스트 메뉴에서 사용할 수 있는 다른 리팩토링을 검사한다. 어떤 것은 매우 강력해서 많은 시간을 절약할 수 있다:

1.       Account용 에디터로 가서 balance() 메소드 이름을 오른쪽 클릭한다.

2.       Refactor >Rename를 선택하고 새로운 이름으로 "getBalance" 를 입력한다.

3.       "Update references to the renamed element"가 체크되었는지를 확인하고 OK를 클릭한다.

이제 통합할 시간이다. 몇몇 코드를 변경하여 테스트를 재실행했다:

1.       Sample 프로젝트를 오른쪽 클릭하여, Team >Synchronize with Repository 를 선택하여 스크린의 밑 부분에 있는 Synchronize 뷰를 연다. 파란색 타이틀 바를 더블클릭하여 이를 크게한다.

2.       툴바의 오른편에 있는 Incoming/Outgoing Mode 버튼을 클릭한다. 이 뷰는 모든 인커밍/아웃고잉 변경을 보여준다. 다시말해서 Eclipse는 CVS와 결부하여 작업공간에 있는 것과 CVS에 있는 것 사이의 델타를 보여준다.

3.       전에 어떤 것도 수행한 것이 없으므로 Structure Compare 뷰에 있는 Sample 프로젝트를 클릭한 후 Commit을 선택한다.

델타가 있었다면 어떤 일이 발생하는지를 보려면 Account 클래스로 돌아가서 deposit() 메소드에 대한 amount 매개변수를 오른쪽 클릭한 다음 Refactor >Rename을 선택한다. 이름을 "anAmount"로 바꾼다. 변경되었다. 테스트를 재실행한다. 모든 것이 통과 될 것이다. 이제 프로젝트를 오른쪽 클릭하고 다시 동기화한다. 그림 5와 비슷한 스크린을 보게될 것이다. Account 클래스를 더블클릭하면 여러분이 만든 델타가 보인다. 이를 유지하고 싶다면 프로젝트를 오른쪽 클릭하여 Commit을 선택한다.

 

그림 5. Synchronize 뷰
Synchronize view

 

 

Ant로 구현하기
프로젝트가 시작되는 대로 모든 XP 팀은 마지막 날에 전체 시스템을 구현해야한다. 이것은 이를 보고자 하는 사람들(이를 테면, 고객)을 위해 시스템을 실행시키기 위함이다. 팀에게 체크포인트도 제공한다. 무엇인가 완전히 잘못되어 간다면 이전 상태로 실행 시스템을 되돌릴 수 있다. 보안망 같이 팀에게 안정감을 주는 것은 없다.

Jakarta의 Ant 프로젝트는 훌륭한 구현 툴이다. 여러분은 XML로 구현 스크립트를 작성한다. 고백하건데 한동안 Ant를 사용하지 않았다면 기본적인 작업을 하기 위해서 많은 정보를 찾았어야 했을 것이다. Eclipse는 작동이 잘되는 Ant 플러그인과 함께 제공된다. 통합은 거의 완벽하다.

하드 드라이브에 파일을 전개 디렉토리로 복사하는 프로젝트를 위한 샘플 구현을 만들어보자:

1.       작업공간에서 Sample을 선택한다.

2.       File >New >Other를 선택한다.

3.       Simple을 선택하고 File을 선택한다.

4.       새 파일을 build.xml로 이름을 정한다. Eclipse는 파일을 만들고 여기에 에디터를 연다. 구현 스크립트는 Listing 9와 같다:

 

Listing 9. Build 스크립트

 <project name="Sample" default="build" basedir=".">
        <property name="project" value="${basedir}"/>
        <property name="tempDirectory" value="${project}/temp"/>     
        <property name="runtimeClasses" 
          location="${project}/lib/runtime.jar"/>
        <property name="deployDirectory" location="c:/deploy"/>
 
        <patternset id="non.test.classes" >
                       <include name="**/*.class"/>                  
                       <exclude name="**/TC_*.class"/>
        </patternset>
 
        <target name="build">
               <antcall target="clean"/>
               <antcall target="init"/>
               <antcall target="build.Sample"/>
               <antcall target="clean"/>
        </target>
        
        <target name="init">
               <mkdir dir="${tempDirectory}"/>
               <mkdir dir="${deployDirectory}"/>
        </target>
 
        <target name="build.Sample">
               <javac srcdir="${project}/src"
                       destdir="${tempDirectory}"
               >
                       <exclude name="**/TC_*.java"/>
               </javac>
 
               <jar destfile="${deployDirectory}/sample.jar">
                       <fileset dir="${tempDirectory}"></fileset>
               </jar>
 
        </target>
 
        <target name="clean">
               <delete dir="${tempDirectory}"/>
        </target>      
</project>

 

Ant는 target에 기반한다. target은 Ant가 실행할 작업 단위를 설명한다. 이 경우 세 개의 target이 있다. 첫 번째 target은 메인 target으로 build라고 한다. project 태그의 default 애트리뷰트는 디폴트 target으로서 구분한다. 그 target은 세 개의 다른 것(clean, init, build.Sample)을 호출한다. 이것이 자바 코드라면 디폴트 target을 델리케이터 메소드로 설명해야한다. 이것이 자바 코드라면 디폴트 target을 델리게이터 메소드로 설명해야한다. 이 메인 target은 먼저 clean을 호출하여 모든 것이 새로운 상태인 것을 확인하고 init을 호출하여 필요한 디렉토리를 설정한다. 그런다음 build.Sample을 호출하고 다시 clean을 호출한다. build.Sample target은 액션이 있는 곳이다. build.Sample로 다음과 같이 할 수 있다:

  • 로컬 하드 드라이브에 전개 디렉토리를 만든다.
  • 테스트 케이스를 제외한 모든 Sample 프로젝트 소스를 임시 디렉토리에 컴파일한다.
  • 임시 디렉토리의 컴파일된 클래스들을 JAR로 압축하고 이를 전개 디렉토리에 넣는다.

Ant 스크립트를 실행하려면 Resource 보기로 가서 build.xml을 오른쪽 클릭하고 Run Ant를 선택한다. 그때 이미 선택된 디폴트 target이 있는 다이얼로그가 뜬다. Run을 클릭한다. 오류가 생기면 Eclipse는 Ant Console을 스크린 바탕에 보여준다. 이것이 Ant의 가장 큰 매력이라고 생각한다. 어떤 것이 잘못되었다면 디버깅은 한 마리의 곰이 될 수 있기 때문이다. 다행스럽게도 Echo Ant target은 System.out.println()과 같은 것을 제공한다. 스크립트에 잘못된 것이 있다면 그곳에 <echo>some helpful message</echo>를 넣으면 무엇이 잘못되었는를 알 수 있다. 지금과 같은 경우 에러는 트릭이 필요하다. Ant는 tools.jar를 찾을 수 없다고 한다. Ant에게 컴파일에 필요한 자바 클래스를 어디에서 찾을 수 있는지를 설명한다. 다음과 같은 순서로 말이다:

1.       Sample 프로젝트를 선택한다.

2.       File >Import를 선택한 후 File System을 선택한다.

3.       설치된 JDK에서 lib 디렉토리를 검색한다.

4.       tools.jar 파일을 선택한다음 Finish를 클릭한다.

이 일련의 과정을 완료하면 Sample 프로젝트에 lib 디렉토리가 생기고 이 안에 tools.jar를 넣는다. 이제 Ant에게 이를 찾는 방법을 명령한다:

1.       Preferences >Ant >Runtime을 선택한다. "Additional classpath entries:"가 밑에 있어야 한다.

2.       Add JARs... 버튼을 클릭하고 Sample/lib/tools.jar를 선택한다. 이제 Ant는 컴파일러를 찾는 방법을 알게된다.

3.       build.xml을 오른쪽 클릭하고 Ant를 재실행한다. 에러가 없어야한다. 그리고 sample.jar in c:\deploy로 끝내야한다.

툴의 효용
이제 "반드시 갖춰야 할" 리스트에 그다지 툴이 많지 않음을 알았을 것이다. 갖고 싶은 다른 Eclipse 플러그인도 있을 것이고 특별한 프로젝트를 지원할 자바 라이브러리도 필요할 것이다. 하지만 많은 프로젝트 팀들이 예상하듯이 많은 툴들이 필요한 것은 아니다. XP를 사용한다면 필요한 관리 툴은 몇 개의 note 카드와 스프레트시트일 것이다. 그외 다른 것은 개발자 툴이고 그 리스트도 적을 것이다. 삶을 편리하게 하는 것이 아니라면 추가하지 말라. 좋은 툴은 차이를 만들어낸다. Eclipse, JUnit, Ant는 내 리스트의 우선순위를 차지하고 있다. 애플리케이션 서버가 필요하면 Tomcat을 사용하라.

참고자료

 

필자소개
Roy W. Miller는 소프트웨어 개발자이자 기술 컨설턴트이다.
작성자: 시간:
라벨:

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)