eek blog, 이야기...

Eclipse Platform 시작하기

Eclipse 플러그인을 이용한 애플리케이션 편집, 컴파일, 디버깅

Level: Introductory

David Gallardo
소프트웨어 컨설턴트
2002년 11월

Eclipse Platform을 소개한다. 기원과 아키텍쳐를 비롯하여 Eclipse의 오픈 소스적 특성과 다중 프로그래밍 언어 지원 등을 다룬다. 간단한 프로그램 예제를 사용하여 자바 개발 환경을 보여줄 것이다.

Eclipse란 무엇인가?
Eclipse는 오픈 소스이며 자바 기반의 확장 가능한 개발 플랫폼이다. 그 자체로 프레임웍이며 플러그인 컴포넌트에서 개발 환경을 구현하는 서비스 세트이다. 다행히, Eclipse에는 Java Development Tools(JDT)를 포함한 표준 플러그인 세트가 포함된다.

대부분의 개발자들이 Java IDE로서 Eclipse를 사용할 수 있다는 것은 큰 행운이며 야망은 여기서 그치지 않는다. Eclipse에는 Plug-in Development Environment (PDE)이 포함되어 있는데 Eclipse를 확장하려는 소프트웨어 개발자들이 주로 흥미를 갖고있다. Eclipse 환경과 완벽하게 통합하는 툴을 구현할 수 있기 때문이다. Eclipse의 모든 것이 플러그인 이기 때문에 모든 툴 개발자들은 Eclipse로 확장을 제공하고 일관성 있고 통합된 개발 환경을 제공하기 위해 레벨을 갖추게 된다.

동일함과 일관성은 자바 개발 툴에만 국한되지 않는다. Eclipse가 자바로 만들어졌지만 자바 언어에만 국한된 것은 아니다. 예를 들어 플러그인도 사용할 수 있고 C/C++, COBOL, Eiffel과 같은 프로그래밍 언어에 대한 지원도 포함할 예정이다. Eclipse 프레임웍은 콘텐트 관리 시스템 같은 소프트웨어 개발과 관련 없는 애플리케이션 유형의 기초로서 사용될 수 있다.

Eclipse 기반 애플리케이션의 예로 IBM의 WebSphere Studio Workbench가 있다. 이것은 IBM의 자바 개발 툴 제품군의 기본을 형성하고 있다. 예를 들어, WebSphere Studio Application Developer는 JSP, 서블릿, EJB, XML, 웹 서비스, 데이터베이스 액세스 지원을 추가했다.

Eclipse는 오픈 소스이다!
오픈 소스 소프트웨어는 특정 권리가 사용자들에게 허용는 라이센스와 함께 배포된 소프트웨어이다. 물론 가장 분명한 권리는 소스 코드는 사용할 수 있는 것이여서 모든 사용자들이 자유롭게 소프트웨어를 변경하고 재배포할 수 있도록 해야한다. 사용자들의 권리의 보호는 copyleft 이라고 하는 장치에 의해 수행된다. 소프트웨어 라이센스는 copyright 보호를 요구하고 이러한 권리가 허용되지 않는 사용자에겐 배포를 금지한다. 이 copyright은 또한 모든 재배포 소프트웨어가 같은 라이센스의 보호를 받을 것을 요구한다.

Open Software Initiative는 오픈 소스가 무엇이며 이러한 기준에 부합하는 라이센스를 인증하는 공인된 비영리 조직이다. Eclipse는 OSI-approved Common Public License (CPL) Version 1.0의 라이센스를 받았다.

Eclipse용 플러그인을 개발하거나 소프트웨어 개발 애플리케이션의 기반으로서 Eclipse를 사용하는 개발자들은 CPL 하에서 사용 및 변경된 모든 Eclipse 코드를 배포한다. 하지만 각자 원하는 방식대로 추가사항을 마음껏 라이센싱 할 수 있다. Eclipse부터 온 소프트웨어에 번들된 재산은 오픈 소스로서 라이센싱 될 필요가 없고 소스 코드는 사용가능 하지 않도록 할 수 있다.

대 부분의 개발자들은 플러그인을 개발하거나 Eclipse 기반의 새로운 제품을 만들기 위해 Eclipse를 사용하지 않더라도 Eclipse의 오픈 소스 성향은 Eclipse를 무료로 사용할 수 있다는 단순한 사실을 넘어서는 중요성을 가진다. 오픈 소스는 혁신을 장려하고 개발자들에게(상용 개발자 포함)에 인센티브를 제공하여 코드를 다시 공용의 오픈 소스 코드 기반으로 기여할 수 있도록 한다. 이렇게 하는 데는 많은 이유가 있지만 아마도 가장 큰 이유는 개발자들이 프로젝트에 기여할 수록 프로젝트는 가치 있는 것이 된다. 프로젝트가 좀더 유용해지면 더 많은 개발자들은 이를 사용하고 이와 관련한 커뮤니티를 만들 것이다. Apache와 리눅스에 커뮤니티가 형성된 것 처럼 말이다.

Eclipse는 누구인가?
Eclipse.org Consortium은 진행중인 Eclipse의 개발을 관리하고 지휘한다. IBM이 4천만 달러로 Eclipse를 개발하고 오픈 소스 프로젝트에 배포한 후 만든 Eclipse.org Consortium은 Borland, Merant, Rational, RedHat, SuSE, TogetherSoft, QNX등의 많은 소프트웨어 툴 벤더들을 기용했다. Hewlett Packard, Fujitsu, Sybase 등의 다른 기업들도 이후 참여했다. 이들 기업들은 Eclipse 프로젝트의 방향과 범위를 정하는 Board of Stewards를 대표한다.

Project Management Committee (PMC)는 Eclipse 프로젝트를 관리한다. 이 프로젝트는 하위 프로젝트로 나뉘고 각 프로젝트마다 대표를 두고있다. 규모가 큰 하위 프로젝트는 컴포넌트들로 나뉘고 이들 컴포넌트에도 대표가 있다. 현재, 대부분의 관리 역할은 최초로 개발된 Eclipse인 Object Technology International (OTI)에서 온 사람들이 관리책임을 맞고있지만 오픈 소스 프로젝트인 만큼 누구나 참여할 수 있다.

Eclipse Workbench
Eclipse를 처음 열면 다음의 첫 화면을 보게된다:

그림 1. Eclipse Workbench

Eclipse Workbench는 view로 알려져있는 여러 패널들로 구성되어 있다. 패널 모음을 perspective라 한다. 기본 perspective는 Resource Perspective인데 이것은 프로젝트를 관리하고 프로젝트의 파일을 검색하고 편집하는데 필요한 기본적인 view이다.

Navigator view로 프로젝트를 생성, 선택 삭제한다. Navigator의 오른쪽 까지의 패널은 편집 영역(editor area)이 다. Navigator에서 선택된 문서 유형에 따라 적절한 에디터 윈도우가 열린다. Eclipse에 특정 문서 타입에 맞는 에디터가 없다면 Eclipse는 외부 에디터를 사용하여 문서를 연다.

Navigator 아래에 있는 Outline view는 에디터에 있는 문서의 아웃라인을 나타낸다. 이 outline의 정확성은 에디터와 문서 유형에 따라 다르다. 자바 소스 파일의 경우 아웃라인은 선언된 모든 클래스, 애트리뷰트, 메소드를 나타낸다.

Tasks view는 작업하고 있는 프로젝트 관련 정보를 모은다. 컴파일 에러 같이 Eclipse가 만들어낸 정보가 될 수 있고 수동으로 작업한 태스크일 수 있다.

메 뉴 또는 툴바 같은 workbench의 다른 기능 대부분은 동종의 애플리케이션과 비슷하다. 한가지 편리한 점이 있다면 스크린의 왼쪽에 보이는 다른 perspective로 가는 "지름길" 툴바이다. Eclipse에는 Eclipse 워크벤치용 사용자 가이드를 포함한 강력한 헬프 시스템과 Java Development Tools 같은 플러그인이 포함되어 있다.

Eclipse를 좀더 관찰하기위해 Navigator에 프로젝트를 만들 것이다. Navigator view에서 오른쪽 클릭을 하여 New=>Project을 선택한다. New Project 대화 상자가 나타나면, 왼쪽의 Java를 선택한다. 표준 Eclipse는 단 한 타입의 자바 프로젝트(Java Project)를 갖고있다. JSP와 서블릿을 지원하기위해 설치된 플러그인이 있다면 웹 애플리케이션용 추가 옵션이 있을 것이다. Java Project를 선택하고 프로젝트 이름이 나타날 때 "Hello"를 입력하고 Finish를 누른다.

Java perspective를 보자. 스크린을 어떻게 관리하고 싶은지에 따라 Window=>Open Perspective=>Java 를 선택하여 현재 윈도우에서 perspective를 변경하거나 Window=>New Window 를 선택하여 새로운 perspective를 선택하여 새로운 윈도우를 열 수 있다.

Java perspective는 자바 개발에 알맞는 view들을 갖추고 있다. 다양한 자바 패키지, 클래스, jar, 파일을 포함하고 있는 계층이 있다. 이 뷰를 Package Explorer라고 한다. 메인 메뉴가 확장되면 새로운 두 개의 메뉴 아이템인 Source와 Refactor가 나타난다.

Java Development Environment (JDE)
자바 개발 환경을 시험해보기 위해서, "Hello, world" 애플리케이션을 만들어 실행할 것이다. 자바 perspective를 사용하여 "Hello" 프로젝트의 오른쪽을 클릭하여 그림 2 처럼 New=>Class 를 선택한다. 대화 상자에 클래스 이름과 같은 "Hello"를 입력한다. "Which method stubs would you like to create?" 아래에 있는 항목 중 "public static void main(String[] args)"를 체크하고 Finish를 누른다.

그림 2. Java perspective에 새로운 클래스 만들기
New Class

이것은 에디터 영역에 Hello 클래스와 빈 main() 메소드를 가진 .java 파일을 만들것이다.(그림 3). 다음 코드를 메소드에 추가한다:

그림 3. 자바 에디터의 Hello 클래스
Hello Class

2.1 버전에서 열기 괄호 또는 더블 쿼트를 입력하면 Eclipse는 자동으로 이들의 파트너를 제공하고 그 내부에 커서를 위치시킨다.

Ctrl-Space를 눌러 코드 완료를 호출할 수 있다 코드 완료는 키보드나 마우스로 선택할 수 있는 제안 리스트를 제공한다. 이 제안들은 특정 객체에 해당하는 메소드 리스트 이거나 for 또는 while 같은 다양한 키보드 기반의 코드가 될 수 있다.

신 택스 체크는 증가하는 컴파일에 의존한다 코드를 저장할 때 이것은 뒤에서 컴파일되고 신택스 에러를 검사한다. 기본적으로 신택스 에러는 빨간 색으로 밑줄이 쳐지고 하얀색 "X"가 있는 빨간 점은 왼쪽 여백에 나타난다. 다른 에러들은 에디터의 왼쪽 공백에 흐린 벌브(bulb)으로 표시된다. 이들은 Quick Fix라고 하는 기능으로 해결한다.

위 코드 예제는 for 구문 옆에 흐린 벌브가 있다. i 선언이 삭제되었기 때문이다. 벌브를 더블 클릭하면 권장 픽스 리스트가 나온다. 이 경우 클래스 필드 i나 로컬 변수 i, 또는 메소드 매개변수 i를 만드는 것을 제안한다. 이중 하나를 클릭하면 코드가 나타난다. 그림 4는 권장 리스트와 로컬 변수를 권장하는 코드이다:

그림 4. Quick Fix 권장
Light Bulb Help

권장 항목을 더블 클릭하여 코드의 적당한 위치에 코드를 삽입한다.

그 림 5 코드가 에러없이 컴파일 되면 Eclipse 메뉴에서 Run을 선택하여 프로그램을 실행할 수 있다. Launch Configurations 대화상자가 나타난다. 오른쪽 밑에 있는 Run 버튼을 누른다. 새로운 탭이 붙여진 패널이 아래쪽 패널(콘솔)에 나타나면서 그림 5 처럼 프로그램의 아웃풋을 디스플레이 한다:

그림 5. 프로그램의 아웃풋
Hello Output

자바 디버거에서도 프로그램을 실행할 수 있다. System.out.println() 옆에 있는 에디터 뷰 왼편에 회색 공백을 더블 클릭하여 main() System.out.println()에 중단점을 만든다. Run 메뉴에서, Debug를 선택한다. 위에 설명한 대로 Launch Configurations 대화창이 나타날것이다. Run을 선택하라. perspective는 Debug perspective로 자동으로 바뀐다. (그림 6):

그림 6. Debug perspective
Debug Output

perspective의 왼쪽 위에 있는 Debug view를 주목해보자. 이것은 콜 스택을 나타내고 프로그램의 실행을 제어하도록 타이틀바에 툴바를 갖고 있다.

오른쪽 위에 있는 패널은 Variables, Breakpoints, Expressions, Display 등의 뷰 탭이 있다. Variables를 클릭하여 i 의 현재 값을 볼 수 있다.

추가 플러그인
애플리케이션의 편집, 컴파일, 디버깅을 위한 JDT 같은 플러그인 외에도 모델링, 구현 자동화, 단위 테스트, 퍼포먼스 테스트, 버전 컨트롤, 설정 관리 같은 완전한 개발 프로세스를 지원하는 플러그인도 사용할 수 있다.

CVS (소스 제어용 오픈소스 Concurrent Versions System)와 작업하기 위한 플러그인이 포함된 Eclipse는 표준이다. Team 플러그인은 CVS 서버와 연결하면서 개발 팀 멤버들이 별다른 변경 절차를 거치지 않고 소스 코드 파일에서 작업할 수 있도록 한다. Eclipse 내부의 소스 제어는 여기서 더이상 다루지 않겠다 .

다음은 다양한 플러그인들이다:

버전 컨트롤과 설정 관리

CVS
Merant PVCS
Rational ClearCase

UML 모델링

OMONDO EclipseUML
Rational XDE (replaces Rose)
Together WebSphere Studio Edition

그래픽

Batik SVG
Macromedia Flash

웹 개발, HTML, XML

Macromedia Dreamweaver
XMLBuddy

애플리케이션 서버 통합

Sysdeo Tomcat launcher

참고자료 참조.

예제: UML 모델링 플러그인
플러그인 예제와 이것이 Eclipse와 어떻게 통합하는지 보려면 OMONDO EclipseUML을 다운로드 하라; 등록을 해야하지만 플러그인은 무료이다. 이 플러그인은 GEF(Graphical Editor Framework) 기반이고 다른 플러그인은 Eclipse용이다. GEF는 Tools 하위 프로젝트의 일부이다. GEF를 다운로드 하려면, Eclipse 웹 사이트(참고자료) 에서 "downloads"를 선택한 다음 "Tools PMC downloads page"링크를 클릭한다. OMONDO (GEF version 2.0 for OMONDO version 1.0.2)에서 권장하는 GEF 구현을 다운로드 해야한다.

일 단 다운로드 되면 다운로드 파일의 압축을 풀고 콘텐츠를 Eclipse 플러그인 디렉토리에 복사함으로서 플러그인이 설치된다. 이 경우 GEF는 압축이 풀려 Eclipse 디렉토리로 들어가야하지만 EclipseUML은 압축이 풀려 곧바로 Eclipse 디렉토리의 플러그인 하위디렉토리로 들어가야한다. 안전을 위해서 임시 디렉토리에 압축을 풀어 이 디렉토리를 복사한다. Eclipse가 실행중이라면 플러그인이 인식하도록 정지시킨 후 재시작해야한다.

EclipseUML (그리고 GEF)이 설치되면 자바 클래스 파일을 만들었던 방식과 같은 방식으로 클래스 다이어그램을 만들 수 있다. Java perspective에서 Package Explorer의 "Hello" 프로젝트에서 오른쪽을 클릭하여 팝업 메뉴에서 New=>Other를 선택한다. New 대화상자의 왼쪽 패널에는 UML용 새로운 옵션이 있을것이다. EclipseUML의 무료 버전은 클래스 다이어그램만을 지원하여 오른쪽의 유일한 옵션은 UML Class Diagram이다. UML Class Diagram을 선택하여 클래스 다이어그램 이름에 "Hello" 등의 단어를 입력한다:

그림 7. Class Diagram 에디터

에 디터 영역에서, 그래픽 에디터가 클래스 다이어그램을 위해 빈 캔버스와 함께 나타날 것이다. 클래스 다이어그램을 만드는 두 가지 방법이 있다: 클래스 다이어그램상의 Package Explorer에서 자바 파일을 드래그 앤드 드롭하여 기존 코드를 역 엔지니어링하는 방법과 빈 다이어그램 위에 툴바에서 사용 가능한 툴을 사용하는 방법이 있다. 첫 번째 방법을 시험하기위해 Person (File=>New=>Class 사용)이라고 하는 새로운 클래스를 만들어 여기에 아래와 같이 두 개의 애트리뷰트를 준다:



/** Person.java

* @author david

*/

public class Person {

private String name;

private Address address;



/**

* Returns the address.

* @return Address

*/

public Address getAddress() {

       return address;

}



/**

* Returns the name.

* @return String

*/

public String getName() {

      return name;

}



/**

* Sets the address.

* @param address The address to set

*/

public void setAddress(Address address) {

      this.address = address;

}



/**

* Sets the name.

* @param name The name to set

*/

public void setName(String name) {

     this.name = name;

}



}

Person.java Hello.ucd를 저장하고 닫는다.

그림 8. Person 클래스 다이어그램
Person Class

UML 에서 자바 클래스를 만들려면, 클래스 다이어그램 윈도우 상단에 있는 툴바의 "New class" 버튼을 클릭한 후 클래스 다이어그램을 클릭한다. New 클래스 위자드가 열리면, 클래스 이름에 Address를 입력하고 Finish를 누른다.

클래스 이름에 오른쪽 클릭을 하고 New=>Attribute 선택을 하여 클래스에 애트리뷰트를 추가할 수 있다. New 애트리뷰트 대화상자에 애트리뷰트 이름, 유형, 가시성 등을 입력한다. 클래스 이름에 오른쪽 클릭을 하고 New=>Method를 선택하여 메소드를 추가한다.

다 이어그램을 바꾸면 다이어그램 밑에있는 Source Editor 윈도우는 변경사항을 반영한다. 마지막으로 Association 버튼을 클릭하고 Person 클래스에서 Address 클래스로 라인을 그리면 클래스 사이의 관계를 도형으로 나타낼 수 있다. 다이어그램은 다음과 같다:

그림 9. Association

이 UML 플러그인은 Eclipse 플러그인의 전형을 나타낸다. 우선, 툴간의 긴밀한 통합을 나타낸다. 다중의 컴포넌트가 작동하고 있다는 것은 명확하지 않다. Eclipse Platform과 JDT의 통합은 완벽하다. 예를들어, Person 클래스가 만들어질 때, 한 애트리뷰트인 Address가 정의되지 않았기 때문에 신택스 에러를 디스플레이한다. 그들은 Address 클래스가 UML 다이어그램에 만들어지면 사라진다.

또 다른 특징은 EclipseUML이 다른 플러그인 (이 경우 GEF)에서 구현될 수 있다.

또 다른 특징은 EclipseUML 플러그인은 기능별 버전이 다양하다. 클래스 다이어그램을 지원하는 기본 플러그인은 무료이다. 하지만 좀더 나은 버전들은 사용료를 지불해야한다.

Eclipse Platform 아키텍쳐
Eclipse Platform은 JDT와 Plug-in Development Environment 같은 플러그인을 지원하는 강력한 서비스를 갖춘 프레임웍이다. Platform runtime, Workspace, Workbench, Team Support, Help 등의 주요 컴포넌트로 구성되어있다.

그림 10. Eclipse Platform 아키텍쳐
Eclipse architecture

Platform
Platform 런타임은 시작할 때 어떤 플러그인이 설치되는지를 발견하고 그들에 대한 정보 레지스트리를 만든다. 시작 시간과 리소스 사용을 줄이기위해, 실제로 필요하지 않는 한 어떤 플러그인도 로딩하지 않는다. 커널을 제외하고 나머지 것은 플러그인으로서 구현된다.

Workspace
Workspace는 사용자 리소스를 관리하는 플러그인이다. 여기에는 사용자가 만든 프로젝트, 그 프로젝트 파일, 파일과 다른 리소스에 대한 변경사항이 포함된다. Workspace는 생성(또는 삭제, 변경)된 파일 같이 리소스 변경에 대한 관련 플러그인을 공지할 역할을 하고있다.

Workbench
Workbench는 Eclipse에 사용자 인터페이스를 제공한다. Standard Widget Toolkit (SWT)과 고급 API인 JFace를 사용하여 구현되고 SWT 상단에 구현된다.

SWT는 Eclipse의 가장 논쟁거리가 되는 부분임이 증명되었다. SWT는 Swing 또는 AWT 보다는 기본 OS의 원시 그래픽 기능으로 매핑된다. 새로운 GUI API를 사용함으로서 Eclipse workbench의 이동성에 제한을 줄 수 있지만, 가장 대중적인 OS용 SWT 포트는 사용할 수 있다.

Eclipse가 SWT를 사용하는 것은 Eclipse 자체의 이동성에만 영향을 준다. Swing/AWT 대신 SWT를 사용하지 않는 한 Eclipse를 사용하는 자바 애플리케이션에는 영향이 없다.

Team support
team support 컴포넌트는 버전 콘트롤과 설정 관리를 맡고 있다. 필요할 때 view를 추가하여 사용자가 사용된 버전 컨트롤이 무엇이든 간에 인터랙팅 할 수 있도록 한다. 대부분의 플러그인은 버전 콘트롤 서비스를 제공하지 않는 한 team support 컴포넌트와 인터랙팅 할 필요가 없다.

Help
help 컴포넌트는 Eclipse Platform의 확장성과 관련이 있다. 플러그인이 Eclipse에 기능을 추가하는 것과 같은 방식으로 help는 애드온(add-on) 네비게이션 구조를 제공하여 툴이 HTML 파일 형태로 문서를 추가하도록 한다.

Eclipse의 미래
많은 사람들이 Eclipse 관련 개발을 하고 있다. 주요 소프트웨어 툴 벤더들은 이를 진행중이고 오픈소스 Eclipse 플러그인 프로젝트의 수는 나날이 늘어나고있다.

이동가능하고 확장가능한 오픈소스 프레임웍은 새로은 아이디어가 아니다. 하지만 강력하고 세련된 디자인 때문에 Eclipse는 전혀 새로운 힘을 불러일으키고 있다. IBM이 4천만 달러 상당의 세계적 소프트웨어를 오픈 소스 분야에 쏟아부음으로서 이러한 현상이 가능해졌다.

참고자료