| Ganymede 시작하기(Bundle and Plug-in) (2008/10/7) | |
JLab 허원진
그동안의 연재한 기사를 바탕으로 어느정도 스키마가 쌓였다. 이제 번들 또는 플러그인을 만들어 보자. 너무 만드는 과정에 집중하지말고 이전 기사의 흐름으로 전체적인 관점에서 봐주었으면 한다.
Bundle or Plug-in, Bundle and Plug-in
Eclipse 2.0 까지의 PDE 개발자들의 고민은 WSAD(IBM사의 개발툴) 호환 문재였다. Eclipse와 WSAD 모두 거이 동일한 플랫폼을 사용했기 때문에 조금 신경만 쓴다면 두가지 환경에서 모두 실행될 수 있는 플러그인 개발이 가능했다. 하지만 3.0 이후 이 문제는 달라졌다. OSGi Bundle인가 Equinox Plugin인가의 문제 이다. Equinox에 OSGi 번들을 올리는것은 문제가 아니지만 그 반대의 경우는 문제가 된다. Equinox의 고유 기능(대표적으로 Extension Point가 있다. 하두 두 플랫폼을 왔다 갔다 했더니 Extension Point가 OSGi R에 포함된것으로 착각할때도 있다.)을 사용한 플러그인의 경우나 Eclipse Platform(Equinox지만 2.0 시절부터 이어저온 클래스 네임으로 굳어져버렸다.)을 사용한 플러그인도 문제가 된다.
우선 Ganymede를 통해 OSGi나 Equinox에 대해 친해지려는 단계의 개발자들은 둘 사이의 어떤 차이가 있다는 정도만 염두하길 바란다. 하지만 현업에서 사용할 개발자들은 문제가 크다. 임베디드 장치안에 OSGi 플랫폼을 이식하는 경우가 많기 때문이다. 정부 과제나 상업 컨소시엄 프로젝트나 이 문제 때문에 서로 싸우는 모습을 종종 보았다. 일단 컨소시엄 구성 과정에서 확실이 OSGi인가 Equinox인가를 명시해야한다.
Bundle Development Environment
Tool
현재로써 Bundle 개발에 가장 최적화된 개발환경은 WSAD 또는 Eclipse이다. 물론 울트라 에디터나 매모장을 이용할 수도 있지만, 이를 통해 디버그/태스팅은 불가능하다. 이클립스 같은 통합 개발 환경이 마음에 안들더라도 참기를 바란다. 번들 개발에 있어는 현재 최고의 환경을 제공한다.
Document
정부 과제라면 아래한글, 현업이라면 보통 워드를 사용할 것이다. 마지막 문서 제출 단계의 포맷은 그렇더라도 초기 문서의 형태는 html으로 하길 조언한다. Eclipse의 Help System간의 연계로 개발자들에게 실질적인 Document를 제공 할 수 있다.
Dual Display
CBD개발의 큰 단점은 개발이 직관적이지 못하다는것이다. 번들 개발도 마찬가지로 내가 어떤 다른 번들을 이용할지, 내 번들은 어떤 기능을 제공할지 확실한 그림을 그리고 있지 않으면 CBD 개발의 늪에 빠지게 된다. 필자가 이 늪을 피하는 방법은 기획/계획 단계의 문서를 계속 보면서 최면을 걸어 버리는것이다. 벽에 모자이크 처럼 개발 키 문서들을 모자이크 처럼 배열해 놓거나 2번째 Display나 3번째 Display에 상주시키고 개발중에 계속 본다.
이 뿐만 아니라 개발중에 다른 번들을 이용하는 부분에 있어서 복잡한 테스팅/디버그가 필요하다. Display는 많으면 많을 수록 좋다. 모니터 하나 더 사고, 한 시간 일찍 퇴근하자.
Bundle & Plug-in Development
걱정도 했고 잔소리도 들었으니 만들어 보자. 과정과 차이점에 중점을 두길 바란다.
1.
OSGi Bundle, Eclipse Plugin 모두 시작은 같다. Plug-in Project를 선택하자.
2.
3.Bundle
Next 위자드에서 Bundle의 경우 standard를 Plugin의 경우 Equinox를 선택 하면 된다. Bundle 프로젝트 이름은 MyBundle Plugin 프로젝트 이름은 MyPlugin으로 하자.
4.Bundle
Activator는 번들의 라이프 사이클을 주관하는 클래스 생성 옵션이다. 거이 대부분의 번들이 Activator를 갖지만 단순히 라이브러리 역할을 하는 번들의 경우 Activator가 필요없다.
Enable API Analysis 특수 자바독 테그를 이용해서 API 사용에 도움을 줄수 있다. PDE 3.4에서 추가된 기능이다.
Next 위자드에서 템플릿을 선택하면 예제가 포함된 번들이 생성된다. 선택하지 말고 그냥 Finish를 누르자. 2번 과정으로 돌아가서 이번에는 플러그인 프로젝트를 만들어 보자. Target Platform에서 Eclipse를 선택하면 된다.
3.Plug-in
번들과는 좀 다른 항목이 추가 됐다.
This plug-in will make contribution to the UI
이 항목을 선택하면 워크벤치를 사용하는 플러그인을 만들게 된다. 쉽게 생각해서 UI(버튼, 창, 위자드, 메뉴등)을 가지는 플러그인을 생각하면 된다. 이 항목을 선택하고 UI를 사용 안하는 플러그인을 만들수는 있지만, 이 항목을 선택 안하고 UI를 사용 안하는 플러그인은 만들 수 없다. 당분간 그냥 이대로 쓰자.
Rich Client Application
여러분이 개발한 번들은 기본으로 한 어플리케이션 개발을 뜻 한다. 이 항목을 체크하게 되면, 여러분이 만든 번들이 단인 어플리케이션 처럼 배포/실행이 가능하다. 예를 들어 FTP 플러그인을 만들었다면 이클립스의 기본 플러그인들(JDT, CVS, PDE 등등)을 배제하고 여러분이 만든 플러그인만 실행된다. 물론 기존의 플러그인도 어플리케이션에 포함할 수 있다.
Next 위자드는 번들과 마찬가지로 템플릿이다.
What a differance between Bundle and Plug-in Project?
Projects
위는 우리가 만든 Bundle과 Plugin 프로젝트 모습이다. 거이 동일하다. META-INF 에 있는 파일을 열어보자.(더블 클릭)
MANIFEST 파일 편집기의 모습이다 어떤 부분이 차이가 날까? 찾아보자.
package mybundle;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
public class Activator implements BundleActivator {
/*
* (non-Javadoc)
* @see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)
*/
public void start(BundleContext context) throws Exception {
}
/*
* (non-Javadoc)
* @see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)
*/
public void stop(BundleContext context) throws Exception {
}
}OSGi Bundle Activator
package myplugin;
import org.eclipse.ui.plugin.AbstractUIPlugin;
import org.osgi.framework.BundleContext;
/**
* The activator class controls the plug-in life cycle
*/
public class Activator extends AbstractUIPlugin {
// The plug-in ID
public static final String PLUGIN_ID = "MyPlugin";
// The shared instance
private static Activator plugin;
/**
* The constructor
*/
public Activator() {
}
/*
* (non-Javadoc)
* @see org.eclipse.ui.plugin.AbstractUIPlugin#start(org.osgi.framework.BundleContext)
*/
public void start(BundleContext context) throws Exception {
super.start(context);
plugin = this;
}
/*
* (non-Javadoc)
* @see org.eclipse.ui.plugin.AbstractUIPlugin#stop(org.osgi.framework.BundleContext)
*/
public void stop(BundleContext context) throws Exception {
plugin = null;
super.stop(context);
}
/**
* Returns the shared instance
*
* @return the shared instance
*/
public static Activator getDefault() {
return plugin;
}
}Eclipse Plugin Activator
Activator 또한 크게 다르지 않다. OSGi 번들은 크게 설명할 내용이 없고, Eclipse Plugin의 activator에 대해서 잠깐 언급하고 넘어 가겠다. Eclipse 1.0 시절에서 플러그인 개발자들에게 Extension Point는 매우 생소한 개념 이었다. 심지어는 Eclipse Project 내에서도 사정은 마찬가지 였다. 이 때 플러그인 간에 객체를 공유하기 위해 사용한 방법이 플러그인 싱글톤 인스턴스를 이용한 방법 이었다. 필자 또한 1.0 시절 부터 2.0 초기 까지 이 방법을 사용 했다. 이 것을 언급 하는 이유는 현업에서 개발하는 플러그인 중에 아직도 이 방법을 많이 사용하고 있기 때문이다. 이 방법의 가장 큰 문제점은 CBD의 모든 장점을 해친다는것이다. 고민하지 말고 제이랩 PDE 게시판을 이용하자. 다음으로는 실행 환경에 대해 알아보겠다.
예전에는 테스트/실행 이라고 해봤자 바이너리 하나 실행하고 조금 복잡하면 뒤에 옵션 정도 주는 정도였다. 하지만 현대 개발 환경은 "도대체 어떻게 키고 꺼?" 라는 말이 나올 정도로 복잡하다. Eclipse는 단순한것 부터 복잡한 어플리케이션 까지 모두 수용하여 테스트/실행 할 수 있는 Launch Configuration을 제공한다. 너무 멋진 환경이라 생각한다. 이클립스 메뉴 Run -> Run Configuration을 누르자.
Debug Configurations
실행/테스트에 따라서 Run/Debug Configuration으로 나뉜다. 위와 같은 창이 뜨면 OSGi Framwork를 선택하고 New Configuration 버튼이나 마우스 우클릭으로 New를 선택하자.
Run Configuration
지금 까지의 기사를 잘 읽어본 독자라면 Configuration 내용이 이해가 될 것이다. 프레임 워크에 어떤 번들을 포함 하고 초기 사작 번들을 선택하는 절차이다. 기본적으로 웍스페이스 상의 모든 번들 프로젝트들이 선택되므로 MyBundle을 제외하고 모두 선택 해제하자. 차후 개발중에 번들을 찾을 수 없다는 에러메세지가 발생하면 이 Configuration부터 확인해야 한다.
Arguments Tab
Arguments Tab 에서 -console을 추가하면 콘솔창을 통해서 OSGi 명령어를 사용 할 수 있다. Run을 눌러보자. 기본 stub외에는 아무 코드도 없으므로 가시적으로 실행을 확인 하려면 콘솔을 이용해야 한다.
Console
ss 명령으로 번들의 상태를 확인한다. 우리가 만든 번들과 OSGi 번들만 실행되있다. 같은 절차로 Plugin을 실행해 보자. Configuration의 Bundles 텝에서 Deselect All을 누른다음에 MyPlugin만 선택 후 Add Required Bundles를 누른다. 다음은 플러그인의 ss 결과 이다.
osgi> ssFramework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.0.v20080605-1900
1 ACTIVE org.eclipse.core.contenttype_3.3.0.v20080604-1400
2 ACTIVE org.eclipse.core.jobs_3.4.0.v20080512
3 ACTIVE org.eclipse.equinox.registry_3.4.0.v20080516-0950
Fragments=6
4 ACTIVE org.eclipse.equinox.common_3.4.0.v20080421-2006
5 ACTIVE javax.servlet_2.4.0.v200806031604
6 RESOLVED org.eclipse.core.runtime.compatibility.registry_3.2.200.v20080610
Master=3
7 ACTIVE org.eclipse.ui_3.4.0.I20080610-1200
8 ACTIVE org.eclipse.help_3.3.100.v20080610
9 ACTIVE MyPlugin_1.0.0
10 ACTIVE org.eclipse.osgi.services_3.1.200.v20071203
11 ACTIVE org.eclipse.core.databinding_1.1.0.I20080527-2000
12 ACTIVE org.eclipse.core.commands_3.4.0.I20080509-2000
13 ACTIVE org.eclipse.core.runtime_3.4.0.v20080512
14 ACTIVE org.eclipse.core.runtime.compatibility.auth_3.2.100.v20070502
15 ACTIVE org.eclipse.equinox.app_1.1.0.v20080421-2006
16 ACTIVE org.eclipse.swt_3.4.0.v3448f
Fragments=23
17 ACTIVE org.eclipse.jface_3.4.0.I20080606-1300
18 ACTIVE org.eclipse.equinox.preferences_3.2.200.v20080421-2006
19 ACTIVE org.eclipse.ui.workbench_3.4.0.I20080606-1300
20 ACTIVE org.eclipse.core.expressions_3.4.0.v20080603-2000
21 ACTIVE com.ibm.icu_3.8.1.v20080530
22 ACTIVE org.eclipse.jface.databinding_1.2.0.I20080515-2000a
23 RESOLVED org.eclipse.swt.win32.win32.x86_3.4.0.v3448f
Master=16osgi>
둘다 기본 stub일 뿐인데 왜이리 ss의 결과가 차이가 날까? 이것이 결국 Bundle과 Plugin의 차이라고 보면 된다. Bundle은 OSGi 프레임워크만 있으면 되지만, Plugin은 Eclipse Platform의 구성 요소 전부가 필요하다.(위 ss의 결과는 플러그인 프로젝트 생성이 Eclipse UI를 사용하는 플러그인이라는 옵션을 선택한 결과이다, 이 옵션을 선택하지 않으면 플러그인 리스트는 좀더 줄어든다.) 위 결과만 놓고 봤을때 "Plugin은 Bundle보다 필요한것이 많다, 리소스를 많이 먹는다"라고 할 수 있다. 하지만, Plugin에 제공되는 매우 편리한 환경이 많다.(번들 프로젝트를 시작해도 어쩔수 없이 Eclipse가 제공 하는 기능을 일부 구현해서 사용하는 경우가 많다)
Summary
OSGi와 Equinox 선택에 있어서 다음과 같은 질문으로 알아보는 방법이 있다.
Q. 객체 공유에 Extenstion Point가 필요합니까?
A. Plugin
Q. 당신이 개발한 번들은 모델을 포함하고 있으면 최종적으로 이식이 수월한 형태의 Core로 배포 하고 싶습니까?
A. Plugin
Q. 임베디드 환경을 기본으로 적은 리소스를 염두 합니까?
A. Bundle
Q. 서버사이드로 데몬처럼 실행되는 프로덕트 입니까?
A. Bundle
Q. Eclipse의 Workbech로 통합 하면 편리한 UI가 필요한 프로덕트 입니까?
A. Plugin
지금 까지 떠들었던 내용은 결국 아래의 표를 완성하기 위한 준비였다.
Bundle(OSGi) Plugin(Equinox) 객체 공유 Service Service, Extension Point Activator BundleActivator Plugin Essentioal Bundle org.eclipse.core.contenttype
org.eclipse.core.jobs
org.eclipse.equinox.registry
org.eclipse.equinox.common
javax.servlet
org.eclipse.core.runtime.compatibility.registry
org.eclipse.osgi.services
org.eclipse.core.runtimeorg.eclipse.core.runtime.compatibility.auth
org.eclipse.equinox.app
org.eclipse.equinox.preferences
관련 제이랩 기사 OSGi 이야기 http://www.jlab.net/news/20050303/news.htm Ganymede http://www.jlab.net/news/20080825/news.htm Ganymede 시작하기(OSGi의 이해와 시작) http://www.jlab.net/news/20080912/news.htm Ganymede 시작하기(Bundle Status) http://www.jlab.net/news/20080923/news.htm
About Author
허원진
제이랩 대표 운영자, Total Eclipse 대표 저자, Eclipse Consultant, Juliet Scandal Project Leader. 이클립스 프로젝트들을 적극 이용해서 저비용으로 쾌속개발을 하는데 관심이 많다. Contact
www.jlab.net
