1. 빌드된 제품으로 실행 할 때만 몇몇 기능이 작동하지 않는 경우

이클립스는 디버그 모드에서 작동할 때, 워크벤치 타겟 플랫폼(개발 타겟)에 있는 플러그인 들 + 워크스페이스 내에 있는 개발중인 플러그인들의 조합으로 수행 됩니다.

그런데, 개발중인 플러그인들은 배포 될 때, 모든 파일이 포함되는 것이 아니라 빌드 설정에 포함된 파일만 빌드 됩니다. 반면 디버그 중에는 이러한 설정과 무관하게 워크스페이스에 있는 모든 파일이 포함되어 실행되므로, 두 결과에 차이가 발생합니다.

예를 들어 개발 중일 때는 포토샵 파일이 있을 수 있지만, 빌드시에는 랜더링된 JPG파일만 나가면 됩니다. 이러한 이유에 의해, 기본적으로 프로젝트에 속한 모든 파일이 빌드되지는 않습니다. 여러분이 프로젝트에 폴더, 아이콘등을 추가할 때, 이 파일이 런타임에 필요한지 여부를 판단하고 빌드 설정에 추가하는 습관을 가지도록 하세요.

2. 제품 업데이트 후 일부 기능이 작동하지 않음

마찬가지로 디버그할 때는 잘작동하는 프로그램이, 런타임에서 업데이트 사이트를 거쳐 업데이트 이후 제대로 동작하지 않는 경우가 있습니다. 대표적인 증세로는 NoSuchMethodException 같은 것이 있습니다. 원인은 간단합니다. 플러그인의 버전을 올려주지 않았기 때문에, 일부 플러그인이 동일한 버전으로 판단, 업데이트가 이루어 지지 않은 것입니다.

'PDE' 카테고리의 다른 글

빌드 자동화 하기 #1 - Hello Ant  (2) 2011.03.07
이클립스 플러그인에 DLL 포함시키기  (0) 2010.12.10
Bundle과 Resource  (0) 2010.10.28
네이쳐와 빌더  (0) 2010.10.15
당신의 Editor는 몇 점입니까?  (0) 2010.10.08
Posted by 지이이이율
,

우선, 아무리 뛰어난 사람도, 처음 맡는 도메인의 문제를 해결해야 할 때는, 삽질이라는 절차를 반드시 거쳐야 합니다. 이 때는 정보의 추상적 깊이, 내포 관계등을 구분할만한 단서가 없으므로, 질문 하기 보다는, 그 분야의 개요를 빨리 익혀야 합니다. 매크로 뷰가 없는 상태에서 질문과 답변을 반복하면, 부분적으로 얕은 지식이 쌓이게 됩니다. 이는 전체를 오해하는 결과를 초래 해, 일반적으로 오히려 해가 됩니다. 가능한한 짧고 간략한 오버뷰 문서를 구하여, 정독합니다.

검색

이클립스는 세상에서 가장 커다란 오픈 프로젝트이며, 따라서 방대한 양의 좋은 문서들이 모두 공개되어 있습니다. 좋은 검색 습관을 갖는 것 만으로도, 당신의 생산성을 10배이상 높일 수 있습니다.

  • 만약 겪고 있는 문제가 SWT / JFace 관련이라면 스니펫을 검색한다. - 모든 링크는 아래에 있습니다.
  • 이클립스에서 널리 사용되고 있는 유형의 문제라면 이클립스 공식 FAQ를 검색한다.
  • 일반적인 큰 개요 유형의 문제라면, 이클립스 위키 문서 또는 리소스를 검색 해 본다.
  • 다른 사람도 겪고 있는 문제라는 생각이 들면, 구글을 검색 해 본다.
  • 구글에 없으면 이클립스 뉴스 그룹에 들어간다. 대개의 질문은 RCP그룹에서 답을 얻을 수 있다.
  • 그곳에서도 답이 없다면 이클립스 뉴스 그룹에 질문한다. 거기엔 월급을 받고 *헌신*적으로 대답해 주는 사람들이 있다. 이곳에서 2~3일 이내(주말 제외)에 답변을 얻지 못하면 다른 돌파구를 마련해야 합니다.

좋은 대답을 가려내는 것은 매우 어려운 일입니다. 알려진 유명인이 대답한 경우에는 (예를 들어 폴 웹스터나 에드먹은 관련 카테고리 내에서 신의 대접을 받고 있습니다) 문제가 없지만 그렇지 않은 경우에는, 가려운 점을 정확히 긁어 주지 못하거나, 국소적인 질문에 대해 너무 큰 개요의 대답을 받는 경우도 종종있습니다. 이럴 때는 상대방이 왜 그런 대답을 했는지 곰곰히 생각 해 보는 것이 중요합니다.

질문을 할 때에는 자신의 의도와 하려는 일을 명확히 기술 하십시오. 대부분의 삽질은 *방법*이나 *시도*자체가 잘못되었을 가능성이 높습니다. 단지 API만 질문하는 것보다 훨씬 폭 넓은 조언을 얻을 수 있습니다.

영어에 대한 두려움을 버리십시오. 이클립스 커뮤니티 포럼에 작성되는 글의 50%가량은 엉터리 영어입니다. (물론 나머지는 그냥 영어죠) 이클립스는 글로벌이니까요. ㅎㅎ. 게다가 컴퓨터 영어는 생각보다 쉽습니다. 단순한 단어를 짧게 조합해서 궁금한 것만 확실히 전달해도 다들 친절하게 대답해 줍니다. 이클립스에 관한 유용하고 훌륭한 정보는 거의 전부라고 해도 좋을 정도로 영어로 작성되 있습니다. 이클립스 5년차 한국 개발자 보다, Java밖에 모르지만 모르지만 영어를 아는 사람이 훨씬 더 유리할 정도로 말이죠.

ps. SWT는 의외로 같은 연구소 내의 MFC/win32개발자들에게 질문하면 간단히 납득할 수 있는 대답을 얻는 경우가 많았습니다.

역공학

문제가 너무 특수하여 대답을 받을 수 없는 경우, 이클립스 내에서 비슷한 기능을 찾아 본다.

  • 해당 기능을 실행하는 다이얼로그등에서 Alt + Shift + F3을 누르면 어떤 플러그인이 그 UI를 기여했는지 파악이 가능하다.
  • 그 상태에서 다시 Alt + Shift + F1을 누르면 그 다이얼로그나 현재 보이는 UI의 활성 클래스 및, UI 컨텍스트, 셀렉션 모델등에 대해 확인이 가능하다. 적당한 클래스를 열어 브레이크포인트를 찍고 관찰하자.
  • Alt + Shift + F2를 누른 상태에서 메뉴나 툴바 아이템을 누르면, 그 메뉴의 메뉴 컨트리뷰션 주소를 알 수 있다.
  • ICommandService 로부터 커매드가 제출 될 때 마다, 어떤 핸들러가 선택되는지 확인 하는 간단한 플러그인을 만들어, 무엇이 실제로 문제를 해결하고 있는지 디버깅해 볼 수 있다.
  • 모든 익스텐젼 포인트는 우클릭을 하여 Find Reference를 선택하면 이 익스텐젼 포인트를 어떻게 사용하는지 알 수 있다. (우선 용의자 플러그인들을 디펜던시에 넣어둘 것)

관련 링크들

'Eclipse Core' 카테고리의 다른 글

P2의 주요 용어 정리  (0) 2010.11.29
Extension Point and Extension  (0) 2010.07.08
어댑터 디커플링  (2) 2009.08.10
Job과 Schedule Rule  (0) 2009.08.08
Posted by 지이이이율
,

Bundle과 Resource

PDE 2010. 10. 28. 18:33

플러그인 내부로 부터 파일을 읽어들이는 작업은, 개발자들이 자주 실수를 저지르는 부분입니다. 많은 사람들이 플러그인의 위치를 알아내어 File을 읽어 들이려고 합니다. 그러나 이러한 접근법은 많은 문제를 일으킬 수 있습니다

Bundle bundle = MyPlugin.getDefault().getBundle(); 
URL resource = bundle.getResource("/icon/test.gif");
Image image = new Image(null, resource.openStream());

뭐 물론 구글해 보면, 위와 같이 번들을 이용해서 리소스를 사용해야 한다는 것은 쉽게 알 수 있습니다. 이 문서가 설명하려는 것은 왜 그렇게 해야 하는가 하는 것입니다.

플러그인은 생각보다 역동적입니다.

우선 플러그인은 jar로 묶여 있을수도 있고 아닐 수도 있습니다. 또, 다른 플러그인들과 같은 위치에 있을수도 있고 그렇지 않을 수도 있습니다. 예를 들어 PDE를 디버깅 모드로 실행하면, Target에 지정된 이클립스의 플러그인들과 작업 중이던 워크스페이스에 있는 플러그인들이 로드됩니다.

뿐만아니라 플러그인은 여러개의 프로젝트로 구성될 수 있으며, 한 개의 jar가 아니는 여러 jar로 구성될 수도 있습니다. (Fragment Project)

게다가 리소스도 동적이에요!

다국어 지원 매커니즘을 번들이 어떻게 지원하는지 간단히 알아 봅시다.

번들에 포함된 모든 리소스는 번들을 통해서 로드됩니다. 여러분이 작성한 아이콘, html 도움말 파일, toc.xml목차등과 같이 플러그인에 담긴 모든 리소스들도 그러합니다. 번들은 리소스를 찾을 때 다음과 같은 매커니즘을 가집니다:

개발자 -> 번들: /icon/test.gif 내놔
번들 -> 이클립스: 지금 사용자 로케일이 뭐냐?
이클립스 -> 번들: ko (한글)
번들 -> 번들 :nl/ko/icon/test.gif 탐색
alt 찾은 경우
번들 -> 개발자: nl/ko/icon/test.gif
else 없는 경우
번들 -> 번들: icon/test.gif 탐색
번들 -> 개발자: icon/test.gif
end

이는 이해를 돕기 위한 그림으로, 정확히 이와 같이 동작하지는 않습니다. 하지만 이렇게 이해해도 좋습니다. 이 이외에도 번들을 통한 리소스 탐색은 몇몇 매커니즘이 있지만, 이 정도면 왜 그렇게해야 하는지는 충분히 이해가 되셨으리라 믿습니다.

Posted by 지이이이율
,