달력

4

« 2024/4 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30





플러그인 개발 기초 학습, Part 2: 리치 클라이언트 애플리케이션 도입하기








플러그인 개발 기초 학습 연재는 순전히 플러그인 개발에 관한 것이다. 그러나 본격적으로 시작하기 전에, 플러그인 개발을 할 수 있는 적당한 환경을 갖추었는지 확인할 필요가 있다. 먼저 할 일은 Eclipse.org에서 PDE(Plug-in Development Environment)를 갖춘 이클립스 배포판을 다운로드하는 것이다. 이클립스 클래식 최신판 다운로드를 권장한다. 이 연재에서는 이클립스 V3.4(M5) 마일스톤 배포판을 사용할 것이다. 이 작업만 완료하면, 시작할 준비가 끝났다(참고자료에서 이클립스를 어디서 찾을 수 있는지 익히고, 만약 이클립스를 처음 접한다면 추가적인 배경 지식을 얻길 바란다).

플러그인 개발을 쉽게 이해하기 위해 본 기사는 그림 1에 있는 작업 흐름도를 따를 것이다. Part 1에서 작업 흐름도의 앞선 다섯 가지 단계를 살펴보았다. 여기서는, 나머지 두 개의 단계를 살펴보고 리치 클라이언트 애플리케이션 소개를 중점적으로 설명하겠다.


그림 1. 플러그인 개발 작업 흐름도
플러그인 개발 작업 흐름도 

빌드하기

빌드 내용 설정은 플러그인 개발 세상에서 매우 중요한 과정이다. 이클립스에서 모든 플러그인 개발 빌드 관련 설정은build.properties 파일에 들어간다.


그림 2. 빌드 설정(build.properties)
빌드 설정(build.properties) 

자동화된 빌드?

플러그인을 위한 자동화된 빌드 설정은 본 기사의 주제 밖이다. 하지만 자주 물어오는 질문이기 때문에 몇 가지 배경지식을 말하고자 한다. 자동화된 빌드를 셋업하는 가장 일반적인 방법은 이클립스 SDK에서 PDE Build 구성요소를 이용하는 것이다. PDE 빌드의 단점은 컴파일로, 입문자들의 기세를 꺾는다. 자동화된 빌드를 설정하는 방법을 참조하는 빠른 방법은 Pluginbuilder 웹 사이트에 있는 플러그인과 도구들을 살펴보는 것이다(참고자료 참조).

샘플 빌드 설정 내용 중앙에 보면 MANIFEST.MF, plugin.xml과 아이콘 파일들이 있다. 또한 거기에는 국제화 지원을 위한 plugins.properties파일과 라이선스 파일 같은 것들이 존재할 수 있다. binary buildsource build가 각각 가지고 있는 것들의 차이를 아는 것이 중요하다. 일반적으로, 이클립스에서 플러그인을 내보낼 때는, 여러분의 친구들의 이클립스 환경에서 사용할 수 있는 바이너리 플러그인으로 내보낸다. 소스 빌드는 플러그인에 포함된 소스 파일들까지 포함하고 있다. 일반 내보내기 옵션에서 소스 빌드를 하도록 선택할 수 있다.

내보내기

플러그인 개발자의 작업 흐름도에서 마지막 단계는 생성한 플러그인을 내보내는 것이다. 이클립스 PDE는 특화된 내보내기 마법사를 통해 이 과정을 매우 간단하게 처리하도록 돕는다. 이 마법사를 사용하려면(그림 3 참조), 간단하게 File > Export를 클릭하고 Plug-in Development 카테고리에 있는 Deployable Plug-ins and Fragments를 선택한다.


그림 3. 플러그인 내보내기 마법사
플러그인 내보내기 마법사 

이 마법사에서 제일 먼저 선택해야 할 옵션은 내보내려는 플러그인이 무엇인가이다. 여기서는 간단하게 예제인 HelloWorld 플러그인이 될 것이다. 다음 과정은 플러그인을 내보낼 목적지다. 우린 선택적으로 플러그인을 ZIP 파일이나 디렉터리로 내보낼 수 있다. 이 마법사에 있는 다른 옵션들은 플러그인 사인과 플러그인에 있는 소스 빌드와 관련된 것이다. 지금은, 이것들은 일단 무시하고 간단하게 마법사에 있는 Finish를 클릭하여 플러그인을 내보낸다(그림 4 참조). 플러그인 manifest 편집기 화면에 있는 Overview 페이지에 보면 마법사를 실행할 수 있는 하이퍼링크가 있는 것을 눈여겨 봐두자.


그림 4. 디스크로 내보낸 플러그인
디스크로 내보낸 플러그인 

잘했다! 지금까지 살펴본 모든 것이 플러그인을 이클립스 워크스페이스에서 하드 디스크로 사용가능한 형태로 내보내는 과정이다. 이런 형태가 되면, 해당 플러그인을 아주 쉽게 친구나 동료 들이 사용할 수 있다. 이것으로 플러그인 개발 작업 흐름도와 관련된 내용은 끝났고, 이제 이클립스에서 리치 클라이언트 애플리케이션을 만드는 방법을 살펴보자.

리치 클라이언트 플랫폼(RCP)

리치 클라이언트 애플리케이션은 이클립스에서 RCP(Rich Client Platform)를 사용하여 만들 수 있다. 전통적으로, 이클립스 플랫폼은 공개 도구 플랫폼으로 설계되었다. 하지만 그렇게 설계되었기 때문에 그 컴포넌트를 어떤 다른 클라이언트 애플리케이션을 만들 때에도 사용할 수 있다. 리치 클라이언트 애플리케이션을 만들기 위해 필요한 최소한의 플러그인 집합을 RCP라고 한다. 좀 더 많은 내용을 알고 싶다면 참조자료를 참조하라.

제품

이클립스 내에서 리치 클라이언트 애플리케이션을 만들려면, 제품 설정(product configuration)이라는 개념을 이해해야 한다. 제품 설정은 플러그인 개발자가 리치 클라이언트 애플리케이션을 만들 수 있도록 PDE에서 제공한다. 제품 설정을 이해하려면, 그걸 사용할 샘플 리치 클라이언트 애플리케이션이 필요하다. Part 1에서 살펴봤던 PDE 템플릿 메커니즘의 장점을 활용하여 하나를 만들 것이다. 플러그인 프로젝트 이름은 rcp로 하고 그것이 리치 클라이언트 애플리케이션임을 확인시켜주고, RCP Application with a view 템플릿을 선택한다(그림 5 참조).


그림 5. 리치 클라이언트 애플리케이션 템플릿
리치 클라이언트 애플리케이션 템플릿 

다음 단계는 제품 설정 파일을 만들어 우리가 앞에서 만든 리치 클라이언트 애플리케이션을 구성할 때 사용할 것이다. 새로운 제품 설정을 만들려면, 플러그인 프로젝트에서 마우스 오른쪽 버튼을 클릭하고 New > Product Configuration을 선택하여 새로운 제품 설정 마법사를 실행한다(그림 6 참조). 모든 기본값을 그대로 놔두고, 제품 설정 파일 이름을 rcp.product라고 한 다음 Finish를 클릭하여 제품 설정 편집기를 실행한다. 다음 절에서 제품 설정 편집기의 여러 페이지를 살펴보자.


그림 6. 새로운 제품 설정 마법사
새로운 제품 설정 마법사 

Overview 탭

플러그인 manifest 편집기와 비슷하게, 제품 설정 편집기의 첫 번째 페이지는 Overview 탭이다(그림 7 참조). 제품 설정, 테스트와 제품을 내보내기 위한 링크, 그리고 제품이 플러그인을 기반으로 했는지 기능(features)을 기반으로 했는지 선택하는 화면으로 구성되어 있다. 애플리케이션을 빠르게 테스트해 보려면, Testing 섹션에 있는 Launch an Eclipse application을 선택하고 리치 클라이언트 애플리케이션이 어떻게 생겼는지 확인해보자.


그림 7. Overview
Overview 탭 화면 

이것이 제품 설정 편집기에서 제공하는 Overview와 관련된 모든 것이다. 제품 설정에서 할 수 있는 기본 동작들에 관심이 있다면, Overview를 다시 살펴보기 바란다.

애플리케이션 폼을 여기서 실행하는 것도 가능하다, Launch an Eclipse Application을 클릭하면 애플리케이션이 팝업으로 뜨는 것을 확인할 수 있다(그림 8 참조).


그림 8. 애플리케이션 실행하기
애플리케이션 실행하기 

Configuration 탭

Configuration 탭은 제품을 실행할 때 사용할 기본 구성요소들을 가지고 있다. 여기에는 제품을 실행할 때 필요한 파일들에 대한 정보가 포함되어 있다. 첫 번째 섹션인 플러그인과 프래그먼트(Fragment, 역자 주: 다른 번들에 속하여 동작하는 번들)에는 제품을 실행할 때 필요한 플러그인과 프래그먼트들이 간단하게 나열되어 있다. 도움이 되는 팁을 주자면, 제품을 만들고 있을 때는 새로운 의존성들을 추가하게 될 것이다. 이럴 때, Add Required Plug-in을 선택하여 제품 설정에 필요한 모든 것을 편하게 추가할 수 있다.

다음 섹션은, 설정 파일로 OSGi에 특화된 구성물로 config.ini 파일이라는 것을 나타낸다. 약 99.9% 가량 이 설정을 그냥 놔두고 이클립스가 생성한 파일을 사용할 것이다. 이 파일에 있는 모든 것은 이미 앞선 플러그인과 프래그먼트 섹션에서 기술한 것이지만, 이런 특별한 형식으로만 이클립스가 이해하고 실행할 수 있다.


그림 9. 설정
설정 

Launching

Launching 탭은 이클립스 기반 제품 실행을 다루는 모든 정보를 담고 있다. Java Runtime Environment 섹션은 플랫폼에 특화된 JRE를 빌드할 때 편리하게 사용할 수 있다. Program Launcher 섹션은 제품을 실행하는 것과 관련된 설정을 할 수 있다. 예를 들어, 보통 개발자들은 eclipse.exe라는 이름 말고 다른 이름으로 실행 파일을 지칭하길 원할 것이다. 실행 파일 이름 위에, 플랫폼에 특화된 아이콘을 사용하여 나타낼 수도 있다. Launching Arguments 섹션에 제품이 필요로 하는 플랫폼에 특화된 매개변수들을 설정할 수 있다. 이것은 Mac OS X과 같이 특정 운영체제에 따라 특화된 동작이 필요할 때 유용하게 사용할 수 있다.


그림 10. 실행
실행 

Splash 탭

Splash 탭을 사용하여 제품과 관련된 스플래시 화면을 부가적으로 설정할 수 있다(그림 11 참조). 예를 들어, 이클립스를 실행하면, 이클립스를 보여주고 플러그인 로딩 과정을 보여주는 간단한 스플래시 화면을 볼 수 있다. 기본적으로, 예제 RCP 애플리케이션은 간단한 비트맵 기반 스플래시 화면 템플릿을 포함하고 있다. 스플래시 화면과 관련된 재미난 것을 시연해 보기 위해, 로그인 스플래시 화면 템플릿(설정 섹션에 있음)을 활용해보자. 로그인 템플릿을 선택한 다음, 제품 설정을 저장하고 애플리케이션을 실행하자.


그림 11. 스플래시
스플래시 

새로운 스플래시 화면과 로그인 그리고 패스워드 창을 확인하라.


그림 12. 커스텀 스플래시 화면
커스텀 스플래시 화면 

Branding 탭

Branding 탭(그림 13 참조)에서는 세 가지 일을 할 수 있다. 창 이미지 수정, 커스텀 about 창 만들기, 부가적인 환영 페이지 만들기다. 창 이미지란 간단하게 애플리케이션 셸 창과 연관된 이미지들을 말한다. 예를 들어, 이클립스를 실행하고, 타이틀 바를 보면 16x16 크기의 이클립스 아이콘을 볼 수 있다. 설정할 수 있는 아이콘 종류가 몇 가지 있다. 대부분의 소프트웨어 애플리케이션은 라이선스, 개발자, 버전 정보가 담긴 about 창을 가지고 있다. 제품 설정 편집기는 이미 만들어둔 이클립스 about 창을 재활용할 수 있게 해준다. 물론 여러분의 이미지와 정보로 변경할 수 있다.

환영 페이지는 사용자가 애플리케이션을 실행하도록 돕는 역할을 할 것이다. 예를 들어, 기본 이클립스 환영 페이지를 보려면, Help > Welcome 메뉴를 선택하면 된다. 만약 여러분의 애플리케이션 용도로 그와 같은 것을 제공하고자 한다면, Branding 탭의 Welcome Page 섹션에서 할 수 있다. 환영 페이지를 작성하는 것은 본 기사의 주제에서 벗어나기 때문에, 여기에 대해 더 자세한 내용을 알고 싶다면, 참고자료에서 이클립스 사용자 도움 기술에 관해 많은 정보를 찾아보길 바란다.


그림 13. 브랜딩
브랜딩 

결론

이 모든 것을 통틀어, 플러그인 개발 기초 학습 연재의 목표는 베스트 프랙티스가 녹아있는 플러그인 개발 기본에 대해 소개하는 것이었다. Part 1에서 예제 플러그인을 만들고 플러그인 개발 작업 흐름도를 살펴보았다. Part 2에서는 플러그인 개발 작업 흐름도를 마쳤고 리치 클라이언트 애플리케이션을 생성했다. 작업 흐름도를 마치고 나면, 플러그인과 이클립스 RCP 기반 애플리케이션을 개발하는 것이 훨씬 수월해질 것이다.

이제, 계속해서 새로 알게 된 지식을 사용하여 플러그인과 이클립스 기반 애플리케이션을 만들어 보라.


참고자료

교육

제품 및 기술 얻기

토론

  • Eclipse Platform newsgroups는 이클립스와 관련하여 논의할 것이 있을 때 가장 먼저 들려야 할 곳이다(이 링크를 선택하면 기본 유즈넷 뉴스 리더 애플리케이션이 실행되고 eclipse.platform을 열 것이다).

  • Eclipse newsgroups에는 이클립스를 사용하고 확장하는 데 관심있는 사람들을 위한 다양한 참고자료가 있다.

  • developerWorks 블로그와 developerWorks 커뮤니티에 참여하라.


:
Posted by 라면스프




플러그인 개발 기초 학습, Part 1: 기본 요소


요약: 이클립스에서 플러그인 개발은 예술과도 같은 것입니다. 플러그인 개념, 특히 OSGi와 이클립스에 대해 낯설다면, 이클립스를 사용하여 플러그인을 만들 수 있도록 제공하는 수 많은 도구를 익히는 것이 다소 어렵게 느껴질 수도 있습니다. 본 기사의 목적은 좋은 평가를 받고 있는 베스트 프랙티스와 함께 기본적인 플러그인 개발 기술을 익힐 수 있도록 하는 것입니다.





플러그인 개발 101 연재는 순전히 플러그인 개발에 관한 것이다. 그러나 본격적으로 시작하기 전에, 플러그인 개발을 할 수 있는 적당한 환경을 갖추었는지 확인할 필요가 있다. 먼저 할 일은 Eclipse.org에서 플러그인 개발 환경(Plug-in Development Environment: PDE)을 갖춘 이클립스 배포판을 다운로드하는 것이다. 이클립스 클래식 최신 버전 다운로드를 권장한다. 이 연재에서는 이클립스 V3.4(M5) 마일스톤 배포판을 사용할 것이다. 이 작업만 완료하면, 시작할 준비가 끝난 것이다(참고자료에서 이클립스를 어디서 찾을 수 있는지 익히고 만약 이클립스를 처음 접한다면 추가적인 배경 지식을 얻길 바란다).

플러그인 개발을 쉽게 이해하기 위해, 본 기사는 그림 1에 있는 작업 흐름도를 따를 것이다. 본 기사의 Part 1에서는 작업 흐름도 중 처음 다섯 개 과정을 살펴볼 것이다. 나머지는 Part 2에서 살펴볼 것이고 리치 클라이언트 애플리케이션(rich-client application)을 집중적으로 다룰 것이다.


그림 1. 플러그인 개발 작업 흐름도
플러그인 개발 작업 흐름도 

OSGi는 무엇인가?

V3.0에서 이클립스는 이전 버전에서 사용하던 못마땅한 플러그인 기술 기반을 OSGi로 교체하는 큰 도약을 거두었다. OSGi Alliance는 OSGi 기술을 책입지는 독립적인 비영리 단체이고 기본적으로 이클립스 재단과 비슷하다. OSGi Alliance는 OSGi 기술을 설명하는 표준 문서 작성을 책임지고 있다. 간략하게 OSGi 기술은 애플리케이션 개발 용도의 서비스 지향적인 플러그인 기반 플랫폼을 제공한다. 다양한 구현체들이 이 표준을 기반으로 하고 있다. 가장 유명한 구현체 중 하나가 Equinox이며 이것이 이클립스에서 OSGi 스펙을 기반으로 구현한 구현체다(참고자료에서 자세한 배경 정보를 참조하라).

플러그인 생성을 자세히 살펴보기 전에, 정확하게 플러그인이 무엇인지 논의해보자. 기술적으로, 플러그인은 독립적으로 실행 가능하며(self-contained) 자기 서술적인(self-describing) JAR(Java™ Archive)다. 플러그인을 실행하는 데 필요한 코드와 리소스를 묶고 있기 때문에 독립적으로 실행할 수 있다. 자신이 무엇이며, 세상으로부터 무엇을 필요로 하는지, 그리고 세상에 무엇을 기여할지에 대한 정보를 가지고 있기 때문에 자기 서술적이다. 플러그인 내부에서 보통 MANIFEST.MF와 plugin.xml 두 개의 서술 파일을 볼 수 있다.

만들기부터 시작하자

플러그인 개발 작업 흐름도의 첫 번째 부분은 플러그인 프로젝트 만들기다. 이클립스에서, New >Project... 메뉴 옵션을 사용하여 쉽게 이 작업을 할 수 있다. 마법사가 보이면, 생성하고자 하는 프로젝트 타입에Plug-in Project를 선택한다.



그림 2. 새 플러그인 프로젝트 마법사
새 플러그인 프로젝트 마법사 

다른 이클립스 프로제트와 마찬가지로, 마법사는 프로젝트 이름을 입력하라고 요구한다. helloworld라고 하겠다. 그리고 타깃 플랫폼을 선택할 수 있는 옵션이 있다. 해당 문맥에서 타깃 플랫폼이란 단순하게 특정 이클립스 버전 용도인지 Equinox와 같은 OSGi 플랫폼 용도인지를 의미한다. 이 경우, 간단하게 이클립스 3.3 버전을 타깃으로 했다. 새 플러그인 프로젝트 마법사 다음 페이지는 플러그인 내용에 대한 것이다.


그림 3. 플러그인 내용
플러그인 내용 

우리가 만들 플러그인을 이클립스에서 사용할 수 있게 하려면, 플러그인 내용 마법사 페이지에서 반드시 폼을 작성해야 한다. 플러그인 식별자는 여러분의 플러그인을 식별할 수 있는 유일한 값을 타나내는 필드다. 다른 어떤 플러그인도 같은 식별자를 사용할 수 없다. 플러그인 버전은 네 부분으로 나뉘어 있다(세 개의 숫자와 문자열 하나). 각각은 major.minor.service.qualifier로 구성된다(참고자료에서 이크립스 플러그인 버전 정하기 가이드를 참조하라). 플러그인 이름은 사람들이 읽기 편한 간단한 이름을 준다. 플러그인 제공자 필드는 플러그인 작성자에 대한 정보를 사람들이 읽기 편한 형태로 기입한다. 간략하게, 실행 환경(EE) 필드는 여러분의 번들을 실행할 수 있는 최소한의 JRE를 명시한다(참고자료).

마법사는 플러그인 활성자(activator)를 설정할 수 있는 옵션을 제공한다. 플러그인 활성자는 단순한 클래스로 플러그인 생명 주기를 제어한다(start-and-stop 메서드처럼 생각하라). 보통, 활성자를 사용하여 기본 설정을 하고 플러그인이 더 이상 필요 없어질 때 자원을 반납하는 용도로 사용한다. 여기서는, 활성자를 사용하여 플러그인이 사용할 UI를 만들도록 하여, RCP(Rich-Client Platform) 애플리케이션을 만들 것이다(참고자료 참조).

플러그인 생성 마지막 단계는 새 플러그인이 기반으로 할 템플릿(그림 4 참조)을 선택하는 것이다. 플러그인 생성에 익숙하다면 이 단계는 보통 생략할 것이다. 하지만, 처음 접하는 사람들은 어느 정도 시작점이 필요하다. 따라서 이클립스 SDK는 다양한 템플릿을 제공하여 쉽게 시작할 수 있도록 하고 있다. 여기서는, 기본 Hello World with a view 애플리케이션을 선택한다.


그림 4. 플러그인 템플릿
플러그인 템플릿 

수정

MANIFEST.MF 내부

MANIFEST.MF 파일 내부에서 사용할 수 있는 헤더들이 궁금하다면, OSGi Alliance에서 가용한 OSGi 명세서를 참조하라(참고자료 참조).

앞선 단계를 마친 다음, 새로운 플러그인이 워크스페이스에 추가됐을 것이다. 그리고 현재 새로 만든 플러그인을 다룰 때 도움을 주는 편집기(그림 5 참조)가 보일 것이다. 편집기의 첫 번째 페이지는 개요(Overview) 페이지다. 이 페이지에는 수정 가능한 플러그인 식별자를 포함하여 플러그인과 관련된 여러 가지 편집 가능한 목록을 가지고 있다. 예를 들어, 이전에 정의했던 식별자(ID)와 버전 필드 그리고 그림 4에서 살펴봤던 템플릿이 있다.


그림 5. 플러그인 편집기(개요 페이지)
플러그인 편집기(개요 페이지) 

확장 기능과 확장 지점

다양한 확장 지점

이클립스 V3.3에는 200개가 넘는 확장 지점을 이클립스 SDK가 제공한다. SDK에서 무엇이 확장 가능한지(다른 말로 하자면, 확장 지점) 목록을 보고 싶다면, 이클립스 재단의 문서 "Platform Extension Points"를 확인하라(참고자료참조).

플러그인 탐험하기 다음 단계는 확장 기능을 추가하는 것을 살펴보겠다. 하지만 자세히 살펴보기 전에, 먼저 확장 가능한 이클립스 플러그인과 관련된 두 가지 중요한 개념을 살펴보자. 간단하게 비유하자면, 확장 기능(extension)은 플러그로 확장 지점(extension point)은 소켓으로 생각할 수 있다. 각각의 확장 지점은 유일하고 적용하기 위해 필요한 조건을 정의하고 있다. 예를 들어, 이클립스는 org.eclipse.ui.editors 확장 지점(소켓)에 우리가 만든 편집기(플러그)를 끼워넣고 사용할 수 있다.

여기서는, 이클립스 도구 모음에 추가할 새로운 확장 기능을 만들 것이다. 그러기 위해 org.eclipse.ui.actionSets 확장 지점에 해당하는 템플릿(앞에서 플러그인을 만들 때 사용한 템플릿과 비슷한 개념)을 사용할 것이다. 플러그인 편집기의 개요 페이지에서 Extension/Extension Point Content 섹션에 있는 Extensions 링크를 선택한다. Add...를 클릭하고 기본값이 채워진 상태로 org.eclipse.ui.actionSets 템플릿(그림 6 참조)을 선택한다.


그림 6. 확장 기능 템플릿
확장 기능 템플릿 

런타임

플러그인에서 중요한 부분으로 자기 서술을 하는 부분이다. 플러그인이 반드시 서술해야 하는 것 중 하나는 외부에 제공하느냐다. 이클립스 문맥에서 이를 공개한 패키지들(exported packages)이라고 한다. 우리의 플러그인에서, 다른 플러그인들이 우리 플러그인 내부에 의존하는 패키지들을 참조할 수 있도록 다른 플러그인들에게 어떤 패키지들을 공개할지 결정해야 한다. 또한 공개한 패키지들을 내부에서만 사용할 것으로 설정할 수도 있는데, 이것은 플러그인 개발자들에게 해당 패키지들은 API로 생각하고 있지 않다고 말하는 것과 같다. 공개한 패키지들을 설정하려면, manifest 편집기에 있는 런타임(Runtime) 페이지를 이용한다.


그림 7. 런타임 페이지
런타임 페이지 

의존성

다양한 플러그인

이클립스 생태계에는 수많은 플러그인들이 있어 찾다가 필요한 것을 헤매기 쉽다. 플러그인을 찾을 때 유용한 두 개의 사이트를 소개하고자 한다. 하나는 이클립스 재단의 프로젝트 목록이고, 두 번째는 이클립스 플러그인 센터(Eclipse Plug-in Central)다(참고자료 참조).

앞선 절에서, 플러그인이 반드시 자신의 기능을 세상에 알리기 위해 해야 하는 일을 설명했다. 자, 이제 다른 플러그인에서 앞에서 말한 기능을 사용하고 싶다고 상상해보자. 해당 기능을 사용하고 싶다는 것을 어떻게 표현할 것인가? 이클립스 문맥에서는 의존성(dependencies)으로 표현한다. 가장 간단한 경우, 플러그인들이 다른 플러그인에 의존할 수 있다. 예를 들어, 만약 여러분의 편집기를 이클립스에서 사용하고 싶다면,org.eclipse.ui.editors 플러그인에 의존해야 할 것이다. 의존성을 기술하려면, 플러그인 편집기의 의존성(Dependencies) 페이지를 사용해야 한다.


그림 8. 의존성 페이지
의존성 페이지 

다른 플러그인에 의존할 때 알아야 할 것은, 플러그인들이 공개한 패키지들에만 선택할 수 있다는 것이다(의존성 페이지의 불러올 패키지(Imported Packages) 부분을 참조하라). 이 부분은 더 어려운 주제인데 여러분의 플러그인이 특정 구현체에 묶이는 것을 원하지 않을 때 유용하다. 예를 들어, XML 파서가 제공하는 com.company.xml.parser 패키지에 의존한다고 생각해보자. 이 때 각기 다른 환경에서 사용할 수 있는 두 개의 플러그인 com.company.xml.parser.mobile과 com.company.xml.parser.desktop 이라는 동일한 XML 파서의 서로 다른 구현체를 머리속에 떠올려보자.

소스 편집기

런타임과 의존성 페이지는 MANIFEST.MF 파일에 기술되어 있는 중요 정보를 가시화해 보여준 것이다. 이 파일 소스를 직접 편집하고자 하는 고급 사용자들을 위해, PDE는 소스 편집기를 제공한다. 소스 편집기는 플러그인 manifest 정의에 사용하는 다양한 헤더에 코드 완성 기능을 제공한다.


그림 9. 소스 편집하기
소스 편집하기 

테스트와 디버깅

플러그인 탐험 다음 단계는 테스트와 디버깅이다. 플러그인 테스트 용도로, 이클립스와 PDE는 자기 호스팅(self-hosting)이라는 개념을 가지고 있다. 자기 호스팅은 간단하게 현재 작업하는 플러그인을 탑재한 새로운 이클립스를 실행하는 것을 말한다. 물론 이 과정에서 실제로는 어떤 플러그인도 공개하거나 배포하지 않는다. 새로운 이클립스를 실행하려면, 개요 페이지에서 테스팅(Testing) 부분(개요 페이지에 있는 Launch an Eclipse application 참조)에서 새로운 런타임 워크벤치를 시작하면 된다. 몇 초 후에, 여러분의 플러그인 샘플 액션이 도구 모음에 추가된 채 새로운 워크벤치 팝업이 뜨는 걸 볼 수 있을 것이다.


그림 10. 이클립스의 자기 호스팅
이클립스의 자기 호스팅 

테스트 주도 플러그인 개발

실제 플러그인을 개발하기 전에 테스트부터 작성하는 것에 관심이 있다면, 테스트만 있는 플러그인을 작성하는 것이 가능하다. 플러그인에 포함되어 테스트를 실행할 수 있는 Plug-in JUnit Test라는 특별한 실행 설정이 존재한다.

디버그 모드에서 자기 호스팅 상태의 플러그인을 실행하려면, 개요 페이지의 테스팅 섹션에서 Launch an Eclipse application in debug mode 링크를 클릭하면 된다. 실제로 여러분의 플러그인을 디버깅하려면, 관련된 중단점을 설정할 필요가 있다. 이클립스에서 디버깅을 처음 해본다면, developerWorks 기사 "Debugging with the Eclipse Platform"을 추천한다. 이 문서가 처음해보는 독자들에게 도움이 될 것이다(참고자료 참조).

플러그인 실행이나 디버깅에 대해 더 상세한 옵션을 설정하려면, 실행 설정(Launch Configuration) 창으로 이동한다. 이 창은 Run > Run Configurations... 메뉴 옵션을 선택하면 볼 수 있다. 여러분의 플러그인과 관련 있는 실행 설정 타입은 "Eclipse Application"이다. 우리가 실제 실행하고 싶은 것이 이클립스 애플리케이션이기 때문이다(그림 11 참조). 실행 설정에서, 여러분은 인자와 같은 것들을 설정할 수 있으며 애플리케이션을 실행할 때 사용할 JRE를 제어할 수 있다.


그림 11. 실행 설정 창
실행 설정 창 

문자열 외부화하기

플러그인 개발에서 가장 흔히 하는 작업이 국제화다. 여러분의 플러그인이 유용하고 많은 사람이 사용하면, 여러분의 플러그인을 여러 언어 환경에서 동작할 수 있도록 해달라는 요청을 받게 될 것이다. 고맙게도, 플러그인과 관련된 문자열을 외부화할 때 필요한 상당량의 작업이 최소화되었다. PDE 안에서 플러그인 개요 페이지에서 마우스 오른쪽 버튼을 클릭하고 Externalize Strings... 메뉴 아이템을 선택하면 마법사를 볼 수 있다. 선택하면, 외부화와 관련된 모든 문자열을 보여주는 화면을 볼 수 있다.


그림 12. Externalize Strings 마법사
Externalize Strings 마법사 

실제로, 이것은 plugin.properties 파일(외부로 빼낸 문자열들을 담고 있다)을 플러그인 내부에 생성하고 MANIFEST.MF 파일에Bundle-Localization 헤더를 추가한다. Bundle-Localization 헤더를 사용하여 간단하게 외부화한 문자열들의 이름과 부가적인 위치를 설정할 수 있다. 여기서는, Bundle-Localization에 "plugin,"이라고 설정했는데, 이것은 다양한 지역의 문자열이 plugin.properties(그림 13 참조), plugin_fr.properties, plugin_de.properties 같은 파일에 존재할 수 있다는 것을 뜻한다. 파일 이름에서 밑줄 다음에 오는 문자는 지역 정보를 나타낸다.


그림 13. plugin.properties 파일
plugin.properties 파일 

이게 다다! 플러그인과 관련된 국제화와 관련된 모든 것을 살펴봤다. 좀 더 많은 정보를 원한다면, 다소 오래되긴 했지만 여전히 유효한 이클립스 코너의 기사 "How to Internationalize your Eclipse Plug-in" 과 "How to Test Your Internationalized Eclipse Plug-In"을 추천한다(참고자료 참조).

manifest 정리하기

우리 여행의 다음 목적지는 manifest 파일들(MENIFEST.MF와 plugin.xml)을 몇 가지 베스트 프랙티스로 정리하는 것이다. PDE는 개요 페이지의 Exporting 섹션을 통해 그와 관련된 편리한 마법사를 제공한다. 마법사가 뜨면(그림 14 참조), 선택할 수 있는 다양한 옵션이 보일 것이다. 기본값들이 보통 타당하지만, plugin.properties 파일에 키값이 없는지 확인하는 것과 같은 특정 옵션들이 있을 수 있는데 이것들이 매우 유용하다.


그림 14. Optimize Manifest 마법사
Optimize Manifest 마법사 

결론

전체적으로, 본 기사의 미션은 몇몇 베스트프랙티스를 기반으로 플러그인 개발 기본 요소를 소개하는 것이다. 우리는 샘플 플러그인을 만들고 일반적인 플러그인 개발 작업 흐름도를 통해 이를 달성했다. 작업 흐름도를 다 익히고 나면, 플러그인을 개발하는 것이 더 쉬워질 것이고 Organize Manifest 마법사와 같이 베스트프랙티스를 사용하여 유지보수 할만큼 익숙해질 것이다. Part 2에서는 리치 클라이언트 애플리케이션 개발을 할 때 이용할 수 있는 도구 사용법과 그림 1에서 살펴보았던 플러그인 개발 작업 흐름도 나머지 부분들을 끝낼 것이다.


참고자료

교육

제품 및 기술 얻기

토론

  • Eclipse Platform newsgroups는 이클립스와 관련하여 논의할 것이 있을 때 가장 먼저 들려야 할 곳이다(이 링크를 선택하면 여러분의 기본 유즈넷 뉴스 리더 애플리케이션이 실행되고 eclipse.platform을 열 것이다).

  • Eclipse newsgroups는 이클립스를 사용하고 확장하는 데 관심있는 사람들을 위한 다양한 참고자료가 있다.

  • developerWorks 블로그에 가입하고 developerWorks 커뮤니티에 참여하라.



Part 2 보기

:
Posted by 라면스프