이클립스(Eclipse)는 많은 사람들에게 흔히 꽤나 훌륭한 자바개발환경으로 널리 알려져있다. 그러나 이클립스를 자바개발환경으로만 생각한다면 이클립스의 잠재력을 무시하는 일! 다음 이클립스 Help에 있는 이클립스의 정의를 읽어보자.
Eclipse is a platform that has been designed from the ground up for building integrated web and application development tooling. By design, the platform does not provide a great deal of end user functionality by itself. The value of the platform is what it encourages: rapid development of integrated features based on a plug-in model.
여기서 중요한 것은 이클립스 그 자체로 사용자에게 기능을 제공하는 것이 아니며 기능적인 요소는 플러그인으로 제공된다는 사실! 애초에 이클립스는 plug-in model을 기반으로 하는 개방성을 목표로 개발되었다. 다음 다이어그램을 참조하면 이 사실은 더욱 명확해진다.
이클립스 플랫폼 자체는 자바 개발환경(JDT)와 플러그인 개발환경(PDE)를 포함하지 않는다. 다시 말하면 자바 개발환경 조차도 이클립스 플랫폼에 확장되는 플러그인 중에 하나 일 뿐이다. 다만 우리가 일반적으로 이클립스를 다운받을 때 Eclipse SDK의 형태로 가져오기 때문에 이클립스가 마치 자바개발환경인 것 처럼 보일 뿐이다. eclipse가 설치된 디렉토리 밑에 plugins 디렉토리를 열어보면 org.eclipse.jdt.* 형태의 이름을 가지는 파일과 디렉토리를 통해 JDT가 플러그인임을 확인할 수 있다. 필자가 개발하고 있는 VICODE는 오른쪽의 New Tool 중에 하나에 해당할 것 이다.
이미 매우 다양한 플러그인들이 개발되어 있다. 여기를 방문하면 다운받아 사용해볼 수 있다. 이클립스에서 데이타베이스 스키마 디자인을 하거나 UML 다이어그램을 그리는 작업등이 이클립스 플랫폼에 플러그인을 추가함으로써 가능해진다.
Platform Runtime은 이클립스 플랫폼의 핵심으로 앞서 이야기한 plug-in model을 책임지는 역할을 한다. 이클립스가 시작될때 현재 플랫폼에 어떤 플러그인이 기여되어있는지를 확인하고 그 정보를 바탕으로 현재의 이클립스 플랫폼을 구성한다. 플러그인이 어떤 방법으로 이클립스 플랫폼에 확장(Extension)되는지는 “확장점과 확장”이라는 제목의 글에서 다룰 예정이다.
현재 저는 연구실 프로젝트 겸 석사학위를 위하여 Verification Integrated CODesign Environment(이하 VICODE)라고 하는 하드웨어/소프트웨어 동시설계 개발환경을 이클립스 플러그인 형태로 개발하고 있습니다. 블로그에서 제가 쓰고자 하는 글은 이클립스 플랫폼을 기반으로 하는 통합개발환경(IDE)를 구축하는 방법에 관한 것 입니다. 따라서 동시설계에 관련된 내용이나 이 툴이 제공하는 기능의 상세 대해서는 생략하겠습니다만, 간략히 하드웨어와 소프트웨어가 모두 존재하는 시스템을 설계하는 도구정도로 생각할 수 있습니다.
올해 초 swing으로 작성하던 어플리케이션을 갑자기 이클립스 기반으로 다시 개발해야 했을 때, 많이 난감했던 기억이 납니다. 이클립스 플러그인 개발에 대한 국내서적은 거의 없었고 번역서 조차도 찾기 어려웠습니다. 물론 몇몇 분들이 쓰신 이클립스 강좌가 있었지만 IDE를 개발하기에는 부족했습니다. 다행히 “자바 개발자를 위한 이클립스 바이블”이라는 책이 출판되었고 이 책을 차근차근 공부하면서 이클립스와 친해질 수 있었지만 책의 구성 탓인지 번역 탓인지 모르겠지만 잘 읽히지가 않아서 인내를 배워야 했습니다.
다른 일에 집중하다가 오랜만에 다시 제가 개발한 플러그인을 뜯어 보았을 때, 잊은 부분이 적지 않았고 제가 개발한 플러그인을 이어서 개발할 후임자를 위해서도 정리가 필요하다고 생각되었습니다. 또한 제가 정리한 글들이 이클립스 플러그인 개발을 처음으로 접하는 분들의 삽질을 조금이라도 줄여드릴 수 있다면 큰 보람이 될 것 입니다.
다른 사람을 가르치면서 배우는 것이 많다는 이야기가 있듯이 그동안 공부한 지식들을 정리 및 공개하여 많은 분들의 피드백을 받으며 제가 공부한 지식을 더욱 굳건히 하고자 하는 욕심도 있습니다. 틀린 부분이나 보충할 부분이 있으면 가감없이 덧글로 남겨주시면 큰 도움이 될 것 같습니다. 질문도 주저없이 덧글로 남겨주시면 제가 모르는 것은 공부해서라도 답변할 수 있도록 노력할 것 입니다.
블로그에서 제가 다룰 것으로 예상되는 부분은 다음과 같습니다. 개발을 진행하면서 틈틈히 쓰는 글이라 예정된 순서가 없고 중간에 필요하다고 생각되는 부분은 추가될 수도 있습니다. 제가 아는 바를 모두 정리한 후 적었던 글들을 체계적으로 정리할 생각입니다.
제가 쓰는 글들이 강좌라고 할 것 까지는 없지만, 인터넷의 강좌나 마소의 기사를 보면 반말(?)을 사용하는 경우가 많아서 저도 글쓰기의 편의를 위해서 반말로 글을 작성하고자 합니다. 플러그인 개발에 대한 글들은 제가 다음의 책들을 공부한 결과를 기반으로 하고 있기에 참조하시면 도움이 될 것 같습니다.
자바 개발자를 위한 이클립스 바이블 Official eclipse 3.0 FAQs The Definitive Guide to SWT and JFace
Eclipse 플러그인 개발에서 action이라고 하는 것을 간단히 정의하자면 메뉴나 툴바의 아이콘을 클릭하였을 때 수행되는 어떤 일이라고 이야기 할 수 있다. IDE에서 소스를 편집하는 editor 혹은 무언가 정보를 보여주는 viewer를 제외하면 대부분의 기능이 바로 action의 형태로 기여된다고 할 수 있다.
action에 대해서 공부하기 이전에 알아야 할 것이 있는데 action set 이라고 하는 녀석이다. 이는 menu와 action으로 구성되어 있는 action을 정의하기 위한 논리적인 집합이라고 생각하면 되는데 일단 다음의 plugin.xml의 일부를 읽어보자.
action에 대한 기여는 action 기여를 위한 확장점(extenstion point)이 있어서 여기에 바로 기여(extenstion)하는 것이 아니라 그 것을 둘러싼 action set에 해당하는 확장점(org.eclipse.ui.actionSets)에 기여 함으로써 이루어진다.
menu는 action의 분류를 제공한다. 아래에 정의되어 있는 각 action들이 UI에 나타나려면 적어도 하나 이상의 menu를 지정해야한다. 위의 플러그인을 수행하면 “Interface”와 “Verification”이라는 최상위 메뉴가 (실제로 그 메뉴에 기여하는 action이 존재하는 경우) 메뉴바에 나타난다. menu의 정의는 메뉴바뿐만 아니라 툴바의 분류가 되기도 하며 어떻게 사용되는지는 action 태그의 menubarPath와 toolbarPath에 달려있다.
메뉴는 하나 이상의 separator를 가진다. 쉽게 설명하자면 인터넷 익스플로러에 파일 메뉴를 클릭하면 4가지 그룹의 메뉴가 나타나는 것을 볼 수 있으며 이는 4개의 separator를 하나의 menu 태그에서 정의하는 것으로 구현될 수 있다. 그리고 각각의 action은 그들이 속해야 하는 menubarPath = “menu의 id/separator의 name” 형태로 자신이 UI의 어디에 나타나야 하는지를 지정할 수 있다. 툴바에 기여하는 경우에는 separator를 지정할 필요가 없다.
여기서 action set의 중요한 속성을 하나 살펴보자. Eclipse 플랫폼은 다수의 플러그인을 포함하여 동작하고 있다. 모든 플러그인이 제공하는 action과 menu가 UI에 모두 나타난다고 상상해보면 어떨까?
나중에 perspective에 대한 글에서 자세히 설명하겠지만, 이와 같은 문제를 해결하기 위해서 플러그인이 제공하는 환경과 기능을 관리할 수 있는 perspective라는 개념을 도입하였다. Eclipse 플랫폼에 기본적으로 포함되어 있는 perspective에는 Java, Debug, Resource등이 있다. Java라는 perspective를 선택하면 자바프로그램을 편집하는데 필요한 에디터와 뷰어 그리고 툴바의 아이콘등이 나타나는 것을 알 수 있다. Java와 Resource perspective를 변경하면서 툴바를 살펴보면 그 차이를 알 수 있을 것이다.
action set에서 visible 속성을 이용하여 action set에 포함되는 menu와 action들이 perspective와 상관없이 무조건 UI에 나타날 것인지 아닌지를 true, false로 지정할 수 있다. 다시 말하면 이 값이 true인 경우 항상 action set에 포함되는 것들이 UI에 표현되고, false인 경우에는 특정 perspective에 action set을 포함시켜 그 perspective로 전환되었을 때만 UI에 표현하게 한다. 자세한 내용은 perspective에 대한 글에서 다룰 생각이다.
지금까지는 action set의 구조와 메뉴(menubarPath)와 툴바(toolbarPath)에 각 action이 어떻게 추가될 수 있는지를 살펴보았다. 지금부터는 action 자체에 대해서 살펴보자. action에서 지정되는 클래스는 IWorkbenchWindowActionDelegate 인터페이스를 상속해야 한다.
public class SimulationInterfaceGenAction implements IWorkbenchWindowActionDelegate { private IStructuredSelection selection;
public void dispose() {
// TODO Auto-generated method stub
}
public void init(IWorkbenchWindow window) {
// TODO Auto-generated method stub
}
public void run(IAction action) {
// TODO Auto-generated method stub
IProject project = (IProject) selection.getFirstElement();
…
…
…
} public void selectionChanged(IAction action, ISelection selection) {
// TODO Auto-generated method stub if (selection instanceof IStructuredSelection) {
this.selection = (IStructuredSelection) selection;
} }
}
action을 구현한 클래스는 위와 같은 구조를 가지게 된다. 툴바의 아이콘이나 메뉴를 클릭하면 해당 action의 run() 메서드가 호출되어 특정 작업이 수행된다. 여기서 추가로 알아야 할 것은 특정 action은 특정 selection과 관계를 맺을 수 있다는 것! 즉 action을 수행하는 대상이 무엇인지 알아야 한다. 예를 들어 JDT에서 메서드의 이름을 바꾸는 리펙토링 액션을 수행한다고 한다면 분명 선택한 메서드가 있을 것이다. 이러한 선택을 selection이라고 하며 selectionChanged() 메서드에서 이 selection을 얻어올 수 있다. 이렇게 얻어온 selection을 통해 특정 영역에 해당하는 action을 수행하게 된다.
action은 selection의 형태에 따라 enable/disable 될 수 있다. 이를테면 어떤 action은 프로젝트(IProject)만을 선택으로 받아들일 수 있고, 어떤 action은 디렉토리(IFolder)에 대해서만 작업을 수행할 수 있다. 이는 plugin.xml에서 selection 태그로 지정할 수 있다. 심지어 name 속성을 이용하면 특정 파일명에 대해서만 action을 제한할 수 있다.
Preference는 IDE에서 흔히 볼 수 있는 환경설정을 의미한다. 우리가 어떤 특정 플러그인을 개발할 때, 그 플러그인에 특화된 환경설정이 필요한 경우가 있다. 예를 들어 설명하자면, 이전에 소개한 바 있지만 Esterel 언어는 소프트웨어 언어인 C로도 컴파일이 되고 하드웨어 언어인 Verilog로도 컴파일이 가능하다.
Preferences in Eclipse
Esterel 언어를 위한 개발환경에서 위와 같은 환경설정이 존재한다면 각 항목의 체크유무에 따라 소스코드의 컴파일시에 생성되는 아웃풋 파일의 종류를 결정할 수 있다. 이와 같은 작업을 위해서 알아야 할 확장점(Extension Point)에는 두가지가 있으며 이를 포함한 plugin.xml의 일부분의 내용은 다음과 같다.
첫번째 확장점인 org.eclipse.ui.preferencePages을 이용해 Preference page에 기여할 수 있으며, 두번째 확장점인 org.eclipse.core.runtime.preferences에서는 환경설정의 기본값을 지정할 수 있다.
우선 첫번째 확장점을 위한 클래스인 VicodePreferencePage를 살펴보자. 이 클래스는 PreferencePage를 상속하며 UI를 만드는 createContents() 메서드, Restore Defaults 버튼을 눌렀을 때 호출되는 performDefaults(), OK 버튼을 눌렀을 때 호출되는 performOk() 메서드등으로 구성되어 있다. 메서드 이름만으로 각 메서드의 역할을 알 수 있을 것이다.
다음 생성자(Constructor)와 performOk() 메서드를 통해서 환경설정을 어떻게 이용하는지 알아보자.
public VicodePreferencePage() {
super(); setPreferenceStore(Activator.getDefault().getPreferenceStore()); setDescription(“Development environment settings for VICODE”);
fCheckBoxes = new ArrayList<Button>();
}
public boolean performOk() { IPreferenceStore store = getPreferenceStore();
for (int i = 0; i < fCheckBoxes.size(); i++) {
Button button = (Button) fCheckBoxes.get(i);
String key = (String) button.getData(); store.setValue(key, button.getSelection()); }
return super.performOk();
}
생성자에서는 setPreferenceStore() 메서드를 호출하여 preference page에서 사용할 preference 저장소를 지정한다. performOk() 메서드에서는 preference 저장소를 얻어와 여기에 setValue() 메서드를 이용해 <key, value>의쌍으로 환경설정을 저장한다. 저장할 수 있는 값들은 boolean, double, float, int, String, long 등의 simple data type중에 하나이어야 한다. 위의 예제는 플러그인이 UI에 기여하는 경우(Activator 클래스가 AbstractUIPlugin를 상속하는 경우)에 해당하며 그렇지 않은 경우(Plugin 클래스를 상속하는 경우)에는 getPluginPreferences 메서드를 사용해야 한다.
정리하면 생성자에서 preference 저장소를 지정한 후, createContents() 메서드에서 preference page에 들어가는 UI를 작성한다. 그리고 각 버튼에 해당하는 코드를 작성한다. 이는 UI에 입력된 정보를 환경설정에 저장하거나 그 반대의 일이 될 것이다.
지금부터는 환경설정의 기본값(Default)를 지정하기 위한 클래스인 Defaults를 살펴보자. 여기서는 간단히 initializeDefaultPreferences() 메서드에서 setDefault() 메서드를 호출해서 각 key에 해당하는 기본값을 지정하기만 하면 된다.
public void initializeDefaultPreferences() {
// TODO Auto-generated method stub
// get preference store IPreferenceStore store = Activator.getDefault().getPreferenceStore(); store.setDefault(“CDE_ESTEREL_C”, true);
store.setDefault(“CDE_ESTEREL_VERILOG”, true);
store.setDefault(“CDE_ESTEREL_BLIF”, false); }
지금까지 Eclipse plug-in 개발시에 preference를 활용하는 방법을 살펴보았다. 아래 첨부한 소스코드를 읽어보면 쉽게 이해할 수 있을 것이다. 예제코드에서 UI 부분은 JDT의 JavaBasePreferencePage 클래스의 것을 응용하였다.
UML Diagram using Draw2D
Draw2D는 GEF에 내장되어 있기도 하지만 standalone으로 사용될 수 있는 그래픽 라이브러리다. GEF에서 그림을 그릴 때 내부적으로 이 라이브러리를 사용한다. Display a UML Diagram using Draw2D 문서를 읽고 금방 그 사용법을 익힐 수 있을 정도로 잘 구성되어 있다. 여러 Figure를 조합해서 하나의 component를 구성하고 그 component 사이에 connection을 정의할 수 있도록 되어있다. 물론 그림 처럼 connection에 해당하는 외관을 변경한다던지 레이블을 추가하는 등의 작업이 가능하다. Eclipse 혹은 SWT 기반의 어플리케이션에서 유용하게 사용할 수 있을 것 같다.
