reshout's blog

Plug-in Development Environment

Plug-in Development Environment(이하 PDE)는 그 자신이 플러그인이면서 플러그인을 개발하는 환경을 제공한다. 우리가 일반적으로 다운받는 Eclipse SDK에 기본적으로 포함되어 있다. 이는 플러그인 개발의 편의를 도모하기 위해 플러그인의 정보를 담고 있는 plugin.xml을 효과적으로 편집할 수 있는 플러그인 설명서 편집기와 개발 중인 플러그인를 실행하고 디버깅할 수 있는 환경을 제공한다.

위의 그림은 여러 페이지로 구성되어 있는 플러그인 설명서 편집기이며 plugin.xml 파일을 쉽게 편집할 수 있도록 도와주는 역할을 한다. 이클립스 3.0에서 개발을 시작하였고 현재는 3.2 버전을 사용하고 있는데 플러그인의 구조가 적잖이 변경되었다. 이전에는 대부분의 정보가 plugin.xml에 저장되었던 것에 반하여 3.2 버전에서는 일부정보가 MANIFEST.MF 파일에 저장된다. 따라서 3.2 버전에서의 plugin.xml은 확장점과 확장에 관한 내용만 담고 있다.

각각의 페이지에 대해서 간략히 설명하자면,

Overview – 플러그인의 ID, 이름, 버전, 제작자등의 정보
Dependencies – 플러그인이 의존하고 있는 다른 플러그인의 집합
Runtime – 런타임에 client에게 export할 package의 집합
Extenstion – 확장정의
Extension Points – 확장점정의
Build – 빌드할때 포함해야할 파일등 플러그인 빌드 관련 설정
MANIFEST.MF – MANIFEST.MF 파일 텍스트 편집기
plugin.xml – plugin.xml 파일 텍스트 편집기
build.properties – build.properties 파일 텍스트 편집기

정리하자면,

Overview, Dependencies, Runtime 페이지를 수정하면 MANIFEST.MF 파일이, Extenstion, Extenstion Points 페이지를 수정하면 plugin.xml 파일이, Build 페이지를 수정하면 build.properties 파일이 수정된다. 텍스트 편집기에서 파일을 직접 수정한 내용도 각 페이지의 폼에 바로 적용되어 상호보완적으로 편집할 수 있다.

플러그인의 실행을 이해하기 위해서는 host 워크벤치와 runtime 워크벤치의 개념을 이해해야한다. 먼저 host 워크벤치는 현재 PDE를 이용해 플러그인을 개발하고 있는 워크벤치를 의미한다. host 워크벤치에서 개발 중인 플러그인의 Run을 구성해 실행시키면 쉽게 말해서 이클립스가 하나 더 뜬다! 이 것이 바로 runtime 워크벤치다.

위의 그림에서는 PDE에서 vicode 플러그인의 Run을 구성하고 있다. 여기서 Plug-ins 탭으로 들어가보면 host 워크벤치와 runtime 워크벤치의 개념을 이해할 수 있다. 여기서 선택된 것은 runtime 워크벤치를 실행할 때 포함하는 플러그인을 의미한다. 다시 말하면 runtime 워크벤치는 host 워크벤치에 포함된 플러그인에 더하여 현재 개발 중인 플러그인을 추가한 워크벤치를 의미한다. (물론 개발하는 플러그인과 의존관계가 없는 플러그인은 제외하고 수행해도 무방하다)

개념을 잡는 것에 도움을 드리기 위해 씌여지고 있는 글이기 때문에 실제 PDE를 사용하는 예제를 수행해보고 싶으신 분은 이클립스 메뉴의 Help > Help Contents를 클릭하시고 나오는 메뉴얼에서 Platform Plug-in Developer Guide > Simple plug-in example을 참조하시기 바랍니다.

1리터의 눈물

지난 주말 이틀동안 한번에 몰아보았던 일본 드라마 “1리터의 눈물”. 드라마 내용이 슬퍼서 1리터까지는 아니였지만 11화를 보면서 내내 울었던 것 같다. 이 드라마는 실제 인물을 바탕으로 하고 있어서 더 마음이 아팠다. 시간이 지날 수록 소뇌가 부서지면서 운동능력을 상실하여 점차 걸을 수도 말할 수도 없게 되는 ‘척수소뇌변성증’이라는 불치병을 앓게되는 15세의 소녀가 이 병을 받아들이고 현실을 인정하면서 끊임없이 삶의 의미를 찾고자 노력하는 과정을 그리고 있다. 주인공인 아야가 25세에 숨을 거두기까지 썼던 일기들이 모여 책으로 출판되었고 일본에서 많은 사랑을 받고 있다고 한다. 지금까지 보았던 어떤 드라마보다도 감동적이였고 많은 생각을 하게 해주었다. 15세의 아야가 의사에게서 자신의 병을 듣고 나서 이런 질문을 한다.

“왜 제가 병에 걸린거죠?”

그 누구도 이 질문에 대답할 수 없었다. 운명으로 받아들이라고 하기에는 너무 가혹하다. 공평하다고 믿고 싶은 이 세상에서 일어나는 이러한 불공평한 일들을 나는 어떻게 설명할 도리가 없다. 하지만 한가지는 분명한 것은 자신의 의지로 장애를 짊어지고 살아가는 사람은 없기에 우리는 서로 돕고 살아야 한다는 것. 건강하게 살아갈 수 있다는 것 만으로도 열심히 살아가야 할 의무가 있지 않을까?

확장점과 확장

플러그인이란 무엇인가? 이클립스에 어떤 기능을 제공하기 위한 것들의 집합이다. 기능을 제공하기 위해서 필요한 것에는 무엇이 있는가? 예를 들어 선택된 파일을 리눅스 콘솔에서 실행하는 기능을 제공한다고 가정하자. 이 때 필요한 것은 이클립스의 어떤 부분(확장점)을 통해 이 기능을 제공할 것인지에 대한 정보(파일을 선택하고 오른쪽 버튼을 눌렀을 때 나오는 팝업메뉴에서? 혹은 파일을 선택하고 툴바의 버튼을 눌러서?)와 이 기능의 이름이 화면에 어떻게 표시 될 것인지, 툴바에 버튼이 추가 된다면 icon 파일은 무엇을 사용할 것인지 등의 정보가 필요할 것 이다. 가장 중요한 것은 메뉴선택이나 툴바버튼이 눌렸을 때 수행되는 일이 무엇인지를 정의하는 것이다.

정리하자면, 이클립스에 기능을 제공하기 위한 플러그인이 가져야 할 정보는 텍스트 데이터와 자바 코드로 나누어 볼 수 있다. 우리는 이 사실로 부터 플러그인의 구조를 유추할 수 있다. 하나의 플러그인 프로젝트는 텍스트 데이터를 담고 있는 plugin.xml 파일과 자바소스코드들로 구성되어 있다. 다음의 다이어그램을 보고 좀 더 상세히 살펴보자.

왼쪽은 이클립스 워크벤치에 해당하는, 즉 이클립스 플랫폼에 기본적으로 포함되어 동작하는 플러그인이며 오른쪽은 우리가 개발하고 있는 플러그인 이라고 하자. 왼쪽의 플러그인은 다른 플러그인이 자신의 기능을 확장할 것을 고려하여 확장점(extenstion-point)를 plugin.xml에 정의하고 있다. 오른쪽의 플러그인은 이 확장점(popupMenus)을 이용하여 확장(extension)하고 있다. 쉽게 이야기 하면 왼쪽의 플러그인은 다른 플러그를 꽂을 수 있는 콘센트를 제공하고, 오른쪽 플러그인은 그 콘센트에 꽂을 수 있는 플러그가 되는 것이다!

확장을 할 때 필요한 정적인 정보는 오른쪽 플러그인의 plugin.xml 파일의 extenstion태그 아래 기술 될 것이며 팝업메뉴가 클릭되었을 때의 동작은 MyObjectAction 클래스에 정의한다. 확장점을 열어주는 입장(Workbench plug-in)에서는 확장하는 방법을 제공해주어야 한다. 즉 확장하는 플러그인(MyAction plug-in)에서 아무렇게나 MyObjectAction 클래스를 정의한다면 제대로 확장이 이루어질 수 없다. 확장점을 열어주는 플러그인에서는 IOjbectActionDelegate 인터페이스를 제공함으로써 확장하는 클래스가 이를 구현하여 자신에게 필요한 코드를 정의하도록 유도한다.

확장점을 열어준 플러그인은 자신을 확장한 플러그인에 대해서 처리해야할 책임을 갖는다. 현재 자신이 제작하고 있는 플러그인에서도 확장점을 얼마든지 정의할 수 있고 이를 다른 사람 혹은 자신이 제작하는 또 다른 플러그인에서 확장이 가능하다. 필자의 경우에는 다른 플러그인이 VICODE를 확장할 가능성을 염두해 두지 않았기 때문에 이클립스 워크벤치가 제공하는 기본 확장점을 이용하고 따로 확장점을 정의해본 경험이 없다.

위의 예제는 실제 VICODE에서 확장자가 *.console인 파일을 선택하고 오른쪽 버튼을 눌렀을 때 나타나는 팝업메뉴에서 리눅스 console 프로그램을 수행하는 기능을 제공하기 위한 것이다. 자세한 내용은 나중에 팝업메뉴 확장하기에 대한 글에서 다루도록 하고 여기서는 확장점과 확장의 관점에서 살펴본다.

이 플러그인은 org.eclipse.ui.popupMenus 라는 확장점에 확장하고 있다. 이 확장점이 필요로 하는 정보가 obejctContribution 태그 아래로 정의되어 있는 것을 볼 수 있다. 정적인 정보는 이렇게 plugin.xml에 정의되고 behavior에 해당하는 내용은 확장점이 기대하는 behavior를 정의한 IOjbectActionDelegate 인터페이스를 구현한 RunConsoleProgramAction 클래스에 정의된다.

이클립스 플랫폼이 구동될 때 플러그인의 정적인 정보를 담고 있는 plugin.xml 파일을 읽어 확장점과 확장의 관계를 고려하여 화면의 UI를 구성한다. 그리고 효율성을 위해 자바 클래스는 그 것이 필요한 시점, 즉 action이라면 메뉴가 클릭되었을 때 객체가 생성되어 수행된다.

CEO 안철수, 지금 우리에게 필요한 것은

CEO 안철수, 지금 우리에게 필요한 것은
안철수 지음/김영사

“CEO 안철수, 영혼이 있는 승부”를 다시 읽은 후 바로 이어서 읽게 된 CEO로서의 안철수님의 두번째 책이다. 책의 초입은 개인적으로 혹은 안철수 연구소를 운영하며 있었던 이야기를 배경으로 그의 원칙과 삶의 태도를 소개한다. 그 다음으로는 조직을 이끌어 나가는 리더로서 여러 사람이 모여서 협업해야 하는 기업의 구성원으로서 가져야할 마음가짐과 태도에 대한 그의 생각을 엿볼 수 있다. 책의 중반에는 우리나라 IT산업의 현실과 정부의 바람직한 역할상 그리고 글로벌 시대의 리더에 대해서 이야기하고 있는데 모든 주제에서 그의 한결같은 삶의 원칙과 철학이 묻어나는 것을 느낄 수 있다. 책의 말미에는 젊은이들에게 전하고자 하는 글이 담겨있다.

곧(?) 적지 않은 인원이 공존하는 회사에서 일해야 하는 나로서는 조직 구성원으로서 가져야 할 마음가짐과 커뮤니케이션의 중요성에 대해서 강조한 부분을 유심히 읽게 되었다. 가장 중요한 것은 서로에 대한 존중과 배려의 마음이 아닐까 생각한다. 사회생활을 시작하기 이전에 이부분을 다시 읽고 많이 생각해보아야 할 것 같다.

젊은 세대에게 전하는 글에서는 열심히 사는 것의 의미와 책을 읽는 이유에 대해서 설명한 부분이 인상적이다. 무엇을 했느냐보다 어떻게 살았느냐가 중요하다는 그의 판단에 나는 스스로가 부끄러웠다. 그래도 고무적이였던 것은 책의 가장 마지막에 적혀있는 책읽기에 관한 글이다.

책이 그 사람에게 영향을 미치려면 어느 정도의 시간이 필요하다는 사실을 알아야 한다. 어떤 경우에는 몇 년 후에 그 효과가 나타나기도 한다. 따라서 책을 읽고 난 후 효과가 바로 나타나지 않는다고 해서 조급한 마음을 가져선 안된다. 좋은 책일수록 서서히 확실한 효과가 나타나기 때문이다. 충분히 사색하고, 책을 읽은 후에 갖게 된 새로운 시각을 현실에 적용하고자 노력한다면, 언젠가는 내재화한 지식과 에너지가 빛을 발할 것이라 믿는다.

올해 많은 책을 읽으면서 어떻게 살아가는 것이 바람직한 삶인지에 대해서 정립할 수 있는 기회를 가질 수 있었다. 하지만 그렇게 정립된 삶의 원칙과 가치관이 아직은 내 삶속에 녹아 있지 않은 부분이 너무나 많아서 ‘과연 나는 나아지고 있는 것일까?’ 하는 고민을 낳는다. 단지 머리속에만 있고 가슴으로 느끼지 못하고 있다는 생각이 들곤 하는데 아직은 조급한 것 일지도 모르겠다. 분명 부족했던 것은 책을 읽고 충분히 사색할 시간을 갖지 못했다는 것. 앞으로는 많은 수의 책을 읽기 보다 책에서 많은 것을 얻어내려고 노력해야겠다.

이클립스 플랫폼과 플러그인

이클립스(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)되는지는 “확장점과 확장”이라는 제목의 글에서 다룰 예정이다.