Search Results for 'IT.com/Eclipse Plug-in/RCP'

4 POSTS

  1. 2009.01.19 Workbench의 내부 들여다보기 -1부- (3)
  2. 2009.01.05 JFace 개발을 위한 환경 설정
  3. 2009.01.05 SWT 개발을 위한 환경 설정 (1)
  4. 2009.01.02 Eclipse Plug-in 학습 방법... (2)

이 글은 Eclipse Corner Article에 기재된 Inside the Workbench: A guide to the workbench internals 의 내용을 기반으로 작성되었다. 링크된 Stefan Xenos의 원문은 문서 버전 1.5에 근거해서 발행되었으며, 필자의 번역본은 2006년 1월에 일부 내용이 수정된 버전 1.6을 근거로 작성하였다. 설명이 필요한 부분은 필자가 각주를 추가했다.

요약

  이  글은 Eclipse 3.1의 Workbench가 View와 Editor를 위한 기반 구조로서 어떻게 동작하는지 설명한다. 목표는 Workbench 내부의 주요한 클래스를 익히고 어떻게 그들이 서로 작용하는지 가르치는 것이다. 이 글은 View, Editor, Action Set 등에 대해 친숙하다는 것을 전제로 쓰여졌다.

Stefan Xenos, IBM
January 6, 2006


1.0 도입

 이 문서는 워크벤치의 내부를 설명하기 위함이지, API를 설명하려는 것은 아니다. 내부의 설계는 자주 바뀌기 마련이다. 만일, 보다 새로운 이클립스에 대해서라면, UI development resources page에서 이 문서의 최신 버전을 구할 수 있을 것이다.

그림 1: View와 Editor의 종속 관계


그림 1은 view와 editor가 어떻게 워크벤치에 의해 다루어지고 있는지를 나타낸다.


 Workbench는 한 개 이상의 WorkbenchWindow를 포함하는데, 다시 각각의 WorkbenchWindow는 0개 이상의 WorkbenchPage를 갖는다. WorkbenchWindow 는 창의 외곽, 다시 말해 trim 위젯[각주:1]들을 제공하며, WorkbenchPage는 창의 본 내용을 제공한다. 이론적으로는 한 WorkbenchWindow가 어떤 수의 page라도 가질 수 있지만, 실제로는 window 한 개 당 하나의 page를 넘지 않는다.

 View와 Editor들은 각각 ViewFactory와 EditorManager를 통해 page의 관리 하에 놓인다. EditorManager는 editor들의 목록과 그들의 공유 리소스를 저장하며, ViewFactory는 view의 목록을 참조 카운트와 함께 관리한다. Workbench 는 EditorReference와 ViewReference를 이용하여 동작하며, 이 글에서도 "editor"나 "view"라는 말은 이 레퍼런스 클래스들을 지칭하는 것이다. Editor와 View의 구별이 그렇게 중요하지 않은 상황에서는, 간단히 "part"라는 용어로 이들을 통칭할 수 있다. part 구현체(구체적으로는 IEditorPart 또는 IViewPart의 구현체이다)는 그것이 최초로 필요한 순간에야 비로소 생성된다. 그림 2에서 보여지듯이 Part에 대한 Reference들은 모든 tab이 가지고 있지만, 실제 그 구현체[각주:2]는 처음 보여질 때 한 번 생성된다.

  Page는 perspective를 가지는데, 이 Perspective는 화면 레이아웃과 그 레이아웃에서 어떤 action set이 사용가능한가에 대한 정보를 가지고 있다. 그림2에서는 Perspective가 view와 editor 영역을 포함하고 있는 것처럼 보일지 모르나, 그들은 단지 (화면에 어떻게 표현될지를 나타내는) 레이아웃을 가지고 있을 뿐이다. 몇 개의 perspective가 각각의 view를 사용하고 있는지를 나타내는 참조 카운트를 Page가 관리하고, 또한 part와 editor 영역에 대해서도 전권을 가지고 관리한다.

  그림 1에서 나타나지 않은 것이 PerspectiveHelper와 EditorAreaHelper 클래스이다. 이 클래스들은 주로 히스토리 관리의 용도로 사용되는데, 이 글에서도 PerspectiveHelper를 Perspective 클래스의 일부인 것 처럼, EditorAreaHelper를 WorkbenchPage클래스의 일부인 것처럼 다루는 것을 볼 수 있다.

그림 2: Workbench 객체들과 각각의 형태



2.0 파트의 내부

그림3: 파트의 구성도

  그림3과 같이, 파트 내부는 몇 개의 객체들로 구성되어 있다. WorkbenchPartReference는 파트의 최상위 표현이다[각주:3]. 쓰이는 곳에 따라, part reference는 IWorkbenchPartReference, IViewReference, IEditorRefenece, IPresentablePart, PartPane의 형태로 노출된다. 이것들은 결국 같은 객체에 대한 서로 다른 인터페이스이다. WorkbenchPartReference와 이를 상속한 클래스들이 I*Reference 인터페이스를 직접 구현하는 것이다. IPresentablePart는 part에 있는 메서드를 직접 재호출하는 단순한 adapter 클래스이다. PartPane은 워크벤치 layout내에 특정 part를 위치시킬 때 필요한 LayoutPart를 구현한다. 그리고 PartPane은 워크벤치의 layout에 있는 컨트롤을 포함시키기 위해 필요한 SWT자원을 관리하기도 한다.

  IEditorPart 나 IViewPart와 같은 part의 구현체는 reference가 소유한다[각주:4]. 이들의 구현체가 생성될 때 PartSite가 인자로 전달된다. 클라이언트 코드의 입장에서 IWorkbenchPartSite나 IEditorSite, 혹은 IViewSite의 형태인 PartSite는 클라이언트의 코드로 하여금 reference와 통신을 하고, Part의 구현체를 위해 만들어진 서비스를 이용할 수 있도록 한다.

 WorkbenchPartReference는 SWT 자원을 필요한 순간에야 비로소 할당[각주:5]한다. 일단 생성되면,  part reference는 반드시 명시적으로 폐기(dispose)되어야 한다. reference 폐기는 Part 구현 자체를 포함한 모든 리소스를 정리하고, 더 이상 추가의 자원을 할당하지 않을 것을 보장하는 것이다. 일단 특정 Part를 다시 사용할 필요가 없을 것이 확실하면, workbench page는 part reference를 폐기한다. SWT 컨트롤들과는 달리, 폐기된 이후에도 reference를 계속해서 사용하는 것이 유효하다. 폐기된 후의 part reference는 자신의 이름을 반환하고, workbench page의 어떤 메서드와도 사용할 수 없다는 것을 빼고[각주:6]는 어떤 흥미로운 점도 없을 것이다. reference의 라이프 사이클을 추적한다는 것이 클라이언트에게는 (거의 불가능할 정도로) 어려운 일이기 때문에, 폐기된 후에도 계속 reference의 public 멤버에 접근하는 것은 허용되고 있다.

2.1 Part Lifecycle

그림 4: WorkbenchPartReference의 상태


  그림 4는 state machine[각주:7]로서의 part의 라이프 사이클을 나타낸다. part reference는 현재 상태를 정수형 필드(멤버 변수)에 저장한다.

Notes:
  • Part는 구현체를 생성하고 있는 중에 특정 상태에 놓이게 된다. 이 상태에서, 구현체는 재귀적으로 재생성되거나 폐기될 수 없다.
  • Part 구현은 해당 Reference가 폐기되면 다시 생성될 수 없다.
  • Part는 한 번 생성 완료되면 lazy 상태로 돌아가지 못한다. 이것은 기능적인 요구사항이 아니라 3.1 구현의 제약이다.
  • 폐기된 이후에도 WorkbenchPartReference 의 public 멤버를 접근하는 것은 계속 유효하다. 그러나, 폐기된 reference는 workbench page의 메서드에 전달되어 사용될 수 없다. (말그대로 더 이상 Page의 일부가 아니기 때문이다.)

2.2 Part 생성

  그림 5: part 생성시의 메세지 순서

 


  그림5는 part의 생성 과정을 나타낸다. 가운데 평행선에 의해 part 생성은 두 단계로 나누어진다. 첫번째 단계에서는 part가 layout에 더해지고, 그리고 나서 실제적인 구현체가 첨부된다. 이것은 두 개로 구분되어지는 동작이며, 따라서 part는  그것이 눈에 보이기 전까지 한동안 그 구현체[각주:8] 없이 존재할 수 있다. 이 그림은 part reference간의 상호작용에 주로 초점을 맞추고 있어, 프리젠테이션에 part를 추가하는 것과 part site를 생성하는 것은 생략되어 있다.

  첨언: part가 성공적으로 생성될 수 있다면 (이를 위해서는 구현체의 init 메서드에서 발생해 WorkbenchPage.openEditor에 메서드까지 전달되는 예외인 PartInitException이 발생되지 않고 통과해야 한다.), layout 에 part를 첨부만 하는 것이 유용한 경우들이 있다. 이러한 경우에 layout에 part를 추가하기 전에 part를 미리 생성하고, 이를 이용해 두 개의 분리된 동작을 하나의 원자성을 지닌 행위로 합치는 것이 가능하다. 이것이 event 전달과 관련된 버그를 만드는지는 알려져 있지 않다.
  1. Trim은 메뉴나 툴 바, 상태 바 등이 위치해 있는 Page 외곽 부분을 의미한다. 아래의 그림 2를 참고한다. [본문으로]
  2. 여기서 구현체는 IWorkbenchPart의 구현체를 의미하며, Part Reference와 Part의 관계는 아래 '파트의 내부' 단원을 참고한다. [본문으로]
  3. 도입부에서도 말했지만 Workbench는 직접 Part 구현체를 다루는 것이 아니라 Part Reference 클래스를 통해 접근한다 [본문으로]
  4. WorkbenchPartReference는 IWorkbenchPart형 멤버변수를 가지고 있으며, 이를 통해 part의 구현체를 소유하고 있다. [본문으로]
  5. 이러한 동작원리는 종종 영어로 lazy라고 표현된다. [본문으로]
  6. 폐기는 part reference와 part의 연결이 끊어지는 것이라고 이해하면 된다. part 이름은 reference 내에 멤버 변수로 들어있는데, 이는 연결이 끊어진 것과 무관하게 참고할 수 있다. 그러나, workbench page의 메서드를 연결이 끊어진 part reference와 사용한다면 수행되지 못할 것이다. [본문으로]
  7. 일종의 상태 집합이라고 생각하면 된다. [본문으로]
  8. 이 글에서는 part reference (IWorkbenchPartReference의 구현 클래스)와 part 구현체(IWorkbenchPart 구현 클래스)를 반복적으로 대조하며 설명하고 있다. 여기서의 구현체는 part구현체이다. [본문으로]
신고

JFace 개발을 위한 환경 설정

Posted 2009.01.05 19:30

 이 글은 지난 글인 SWT를 위한 환경 설정에서 이어진다. 작성한 org.eclipse.swt 프로젝트에 라이브러리와 소스를 추가함으로써 JFace를 작성할 수 있는 환경을 구성해보자.

 작성한 테스트용 프로젝트인 MyProject를 열고 프로젝트 속성(Properties)를 확인해 보자. Library 탭을 보면, swt.jar만이 라이브러리 명단에 포함되어 있음을 알 수 있다. 그렇다면, 자연스레 다음과 같은 생각이 들 것이다.

그럼 JFace는? (최경주 골퍼의 모 광고 패러디다.--;)

 그렇다. 기존에 작성한 SWT 개발 환경만으로는 JFace Application을 작성할 수 없다. 이번 환경 설정에서 할 일은 기존의 환경에 JFace Application 작성 시 필요한 라이브러리와 소스를 추가하는 것이다.

 우선 위와 같이 기존 org.eclipse.swt 프로젝트의 Properties > Java Build Path 에서 Libraries 탭을 누르고 Add Variable을 선택한다. 그러면 다음 화면과 같이 각종 경로를 정의한 변수들을 볼 수 있다.

 우리는 Eclipse 의 설치 경로를 나타내는 ECLIPSE_HOME 변수를 사용할 것이다. 이를 선택하고 "Extend" 버튼을 누른다. 그러면 Eclipse 설치 폴더를 기준으로 하위 폴더를 선택할 수 있다. (다른 말로, ECLIPSE_HOME 이 가리키는 폴더를 중심으로 하위 폴더로 선택을 확장 해 나갈 수 있다.)

 

 plugins 폴더를 찾아보면 org.eclipse.jface로 시작하는 jar 파일이 있다. 이를 추가한다.

 여기서 많은 이들이 쉽게 놓치는 주의 사항이 하나 있다. 이렇게 관련 라이브러리를 추가하면 끝나는 것이 아니라, 추가한 JFace 라이브러리를 외부로 노출하여야 한다. 그래야 MyProject 와 같이 org.eclipse.swt 프로젝트를 사용하는 외부 프로젝트에서 사용할 수 있다.


 Java Build Path의 Order and Export 탭에서 다음과 같이 jface관련 라이브러리를 노출한다.

 JFace는 이 이외에도 몇 몇 라이브러리를 추가로 요구한다. 동일한 요령으로 JFace를 동작하기 위한 필수 라이브러리인 org.eclipse.equinox.common_xxx.jarorg.eclipse.core.commands_xxx.jar 를 외부로 노출(Export) 시켜준다. 최종 모습은 다음과 같다.

 그럼 MyProject 인 형태의 JFace 클래스를 작성해 보자. (참고로, 이전 SWT환경 설정에서 MyProject를 BuildPath에 org.eclipse.swt를 잡아주었다) 클래스명은 JFaceTest로 다음과 같이 작성한다.

import org.eclipse.jface.window.ApplicationWindow;
import org.eclipse.swt.widgets.Display;

public class JFaceTest extends ApplicationWindow{
 public JFaceTest() {
  super(null);
 }

 public static void main(String[] args) { 
  JFaceTest window = new JFaceTest();

  window.setBlockOnOpen(true);
  window.open();
  Display.getCurrent().dispose();
 }
}

이를 실행시키면 다음과 같은 화면을 볼 수 있다.

 일단 실행 환경은 다 작성하였지만, 문제가 하나 있다. 작성한 소스에서 CTRL + 마우스 왼쪽 클릭을 이용하여 ApplicationWindow의 소스를 확인해보자.

 위 화면과 같이 org.eclipse.jface_xxx.jar의 ApplicationWindow 소스는 첨부되어 있지 않다고 나올 것이다. 특정한 자바 라이브러리를 공부하면서 소스를 보지 않고 학습한다는 것은 학습 자체의 한계를 가져온다.

 다음과 같이 소스를 첨부할 수 있다.

 org.eclipse.swt 프로젝트에서 Properties > Java Build Path 를 선택하고 Libraries 탭을 보면 org.eclipse.jface_xxx.jar 가 보인다. 이를 화면에서 + 표시를 눌러 tree를 확장하면 다음과 같이 Source Attachment 항목 을 볼수 있다. Edit 버튼을 눌러 이를 수정한다.

 변수 명을 이용하여 적절한 소스의 위치를 지정할 것이다. 이클립스 plugins 폴더에 소스파일도 같이 있으므로 ECLIPSE_HOME 변수를 선택하고 Extension(확장) 버튼을 누른다.

아래와 같이 plugins\org.eclipse.jface.source_xxx.jar를 선택한다.

 이제 소스가 첨부되었으므로, 다시 한번 ApplicationWindow 클래스의 소스 보기를 시도하여 보자.

 JFace 라이브러리 내부에 있는 ApplicationWindow의 소스를 확인할 수 있다.

 위에서 보았듯이, 이클립스 플러그인의 소스는 주로 플러그인명.source의 형태로 제공된다. org.eclipse.jface_xxx.jar 이외에도 다른 SWT/JFace 개발 관련 라이브러리들도 필요시 같은 형태로 소스를 찾아 첨부해주면 된다.

 예를 들면, org.eclipse.jface.text_xxx.jar 를 필요에 의해 라이브러리로추가했다면, 해당 라이브러리에 org.eclipse.jface.text.souce_xxx.jar 를 소스 첨부하면 된다.

신고

SWT 개발을 위한 환경 설정

Posted 2009.01.05 15:11

 이전 글 이클립스 플러그인 학습 방법에서 분야 별로 차근차근 학습하여야 한다는 의견을 제시하였다. 그렇다면 플러그인 관련 학습 이전에 SWT/JFace 관련 학습이 선행되어야 할텐데, 이 말은 플러그인 전용 프로젝트에 관해 배우기 전 우리가 이미 알고 있는 Java 프로젝트에서 독립적으로 SWT/JFace의 학습이 가능해야 한다는 의미와도 같다.

 이번에는 첫 대상이 되는 SWT 개발을 위한 실제 개발 환경 설정을 해 보겠다. 미리 밝히건데, 본 내용은 Eclipse의 SWT 사이트(http://www.eclipse.org/swt/)에서 제시하는 설정 방법을 근간으로 하고 있다.

  Eclipse의 SWT 사이트에서 원하는 플랫폼의 SWT를 다운로드 한다. 만일 3.4 버전의 window플랫폼 용이라면 파일명은 swt-3.4-win32-win32-x86.zip이다.

 이제 압축 파일을 eclipse 프로젝트로 import하여 사용할 것이다. 이클립스 프로젝트 간에는 서로 참조가 가능하기 때문에 위 swt 라이브러리를 eclipse 프로젝트로 만들어 놓으면, 다른 프로젝트에서 이를 라이브러리 사용하듯이 참조할 수 있게 된다.

우선 다운로드 받은 압축 파일을 eclipse 에서 import하자.(참고로 본 환경 설정은 eclipse 3.4를 사용하여 진행하였으나, 이클립스의 다른 버젼도 같은 개념으로 설정 후 사용하면 된다.)

File > Import > Existing Projects Into Workspace를 선택함

Select archive file 을 선택하고 방금 다운로드한 swt 관련 압축파일을 지정함.
(지정 후 Eclipse가 org.eclipse.swt라는 프로젝트를 자동으로 감지)

 이로써 간단하게 프로젝트 import 작업은 끝났다. 이제 바로 swt 개발을 진행할 수도 있다. (하지만 약간의 마무리 단계가 남아있다.)

 테스트도 할 겸, 일단은 Java Project를 이용해 간단한 SWT/JFace를 작성하고, 방금 import한 SWT 관련 프로젝트와 연계해 보겠다. 우선, MyProject란 이름으로 Java Project를 작성해 보았다.

 MyProject 프로젝트가 org.eclipse.swt 프로젝트를 참조하도록 하기 위해, MyProject의 Properties > Java Build Path 에서 Project 탭을 선택하고 org.eclipse.swt 프로젝트를 추가한다.

 

 이 후 MyProject에서 SWT 관련 소스를 작성하면, SWT 클래스라 할지라도 다음과 같이 Content Assist 기능이 동작한다.

SWT 관련 프로젝트 설정이 끝났다. 이제 MyProject에서 SWT를 이용하는 간단한 프로그램을 작성해 보자. 작성 코드는 다음과 같으며, 클래스명은 SWTTest라 하였다.

import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;


public class SWTTest {

/**
* @param args
*/
public static void main(String[] args) {
  Display display = new Display();
  Shell shell = new Shell( display );
  shell.open();

  while( !shell.isDisposed()) {
    if ( ! display.readAndDispatch()) {
     display.sleep();
   }
  }

  display.dispose();
 }
}

실행하면 다음과 같은 창이 뜬다.

신고

Eclipse Plug-in 학습 방법...

Posted 2009.01.02 02:01

이클립스 플러그인 개발을 시도해 보았는가? 좌절해 보았는가?

 Eclipse Plug-in 개발을 학습하기란 그리 쉽지 않다. (오해는 말길 바란다. 개발이 아니라 학습이 어렵다는 말이다.) 사실 Eclipse Plug-in 개발은 알아야 할 내용은 많은 편이지만, 정작 난이도는 알고 나면, 그렇게 높지 않다는 것이 현재 결론이다. 그럼에도 불구하고 Plug-in 개발을 배우는데 적잖은 고생을 했고, 지금도 하고 있다.

 일부 국내의 플러그인 관련서들이 독자를 고려하지 않은 번역 혹은 어지러운 내용 전개로 머리를 어지럽히고, 이 중 몇몇은 오타까지 남발하고 있다. 본인도 아직 플러그인 개발의 초급 단계라 생각하지만, 어쨌건 한 번 고생을 한 사람으로서, 플러그인 학습을 시작하는 사람들이 고생을 조금이라도 덜 하길 바라는 마음에서 "플러그 인 학습 로드맵"에 대한 개인적인 의견을 적어보게 되었다.

 본 학습 로드맵을 참고하는데 다음과 같은 주의 사항이 있다.

  • 필자는 학습 시 이해를 중시하는 스타일이다. 예를 들어, 예제를 작성할 때 "일단 해보세요. 이 중 일부는 저기 뒤에 챕터에 나와요"라는 스타일의 가이드는 본인에겐 매우 답답하다. 따라서 다른 스타일의 사람들에겐 RCP/Plug-in을 무조건 만들어 보고 따라하는게 더 좋을 수도 있다.
  • SWT JFace 부터 시작한다는 개념의 이 학습 로드맵은 전체적인 소요시간 면에서 더 비용이 많이 드는 방법이라 할 수 있다. 이해도와 학습 시간의 trade-off 관계를 생각하면 된다.
  • 상세한 정보는 계속 업데이트가 될 예정이다. 큰 흐름은 변하지 않겠지만, 사이트나 책을 검증하는 데로 업데이트 할 것이다.

 그럼 본격적으로 로드맵을 살펴보자. 우선, 이클립스 플러그인 개발은 하나의 기술로 이루어지지 않는다는 것을 이해해야 한다. 이클립스로 플러그인을 만들면 알게 모르게 SWT, JFace, OSGi(Equinox)를 기본으로 사용하게 되며, 이를 기반으로 이클립스에서 제공하는 plugin 혹은 rcp 관련 개발 프레임워크를 사용하게 된다. 이를 모르고 플러그인 관련 책/웹 사이트가 제시하는 예제를 무작정 따라서 학습한다면, 범벅이 되어 제시되는 여러 기술이 정리가 되지 않아 머리가 매우 어지럽게 된다.

 따라서, 각각의 기술을 단계별로 이해하는 것이 중요하다. 다음과 같은 흐름을 제시한다.

 국내의 몇몇 서적이나 Eclipse 도움말의 챕터 순서는 이와는 사뭇다르다. 그 순서도 나름의 의미가 있다. 그렇지만, 이렇게 기반이 되는 기술 순서로 학습하면 지금 작성하는 코드가 어디에서 나왔는지를 알 수 있음은 물론, 플러그인의 내부까지도 상상할 수 있게 된다. JFace는 SWT를 상위레벨로 재포장하고 있으며, 플러그인 개발은 다시 SWT/JFace와 OSGi 번들의 개념을 재포장하고 있다. 위의 로드맵을 따라가면 어떻게 재포장 되는지를 느끼게 되며, 이는 학습에 상당한 도움을 준다. 물론 앞서 제시했듯이, 시간은 더 많이 걸린다. 그러나 이것도 상대적인 개념으로, 배경과 구조를 이해하고 학습하느냐 마느냐의 학습량 차이에서 비롯된다고 본다.

 또 중요한 한가지는 플러그인 개발 이전 단계에 있는 SWT, JFace, OSGi 를 철저하게 외우고 있어야 하는 것은 아니라는 점이다. 전체를 가볍게 한번 보고 플러그인/RCP개발 시 "이런 뭐시기가 있었는데..." 하면서 참고했던 자료를 다시 보면된다.

 이하는 각 단계에 대한 간략한 설명이다. 사이트나 서적에 대한 정보는 계속 업데이트 할 예정이다.

SWT 사이트 http://www.eclipse.org/swt/examples.php
서적 오타가 좀 있지만, SWT를 맛보기에는 좋다.
JFace 사이트 Creating JFace Wizards(Eclipse Corner Articles) - http://www.eclipse.org/articles/article.php?file=Article-JFaceWizards/index.html
서적
OSGi 사이트 http://xguru.net/blog/451.html (Getting Started With OSGi를 번역함) 필수적인 것은 아니지만, 이클립스 플러그인 자체가 OSGi 번들이므로 개념을 대강만 알아도 플러그인에 대한 이해가 깊어진다. 다음을 참고한다.
플러그인 개발 관련 사이트

Eclipse Corner Articles - http://www.eclipse.org/articles/index.php (광범위한 101개의 글)
Observe Eclipse(일본, 추천)- http://www13.plala.or.jp/observe/index.html(단계별 정리가잘 되어있음)
Observe Eclipse의 네이버 번역 링크 - http://j2k.naver.com/j2k_frame.php/korean/www13.plala.or.jp/observe/index.html#pde

서적
RCP 관련 사이트 RCP Quick Start - http://rcpquickstart.com/
Eclipse Tips - http://blog.eclipse-tips.com/ (SWT/JFace ~ RCP)
영문 developerWorks -
http://www.ibm.com/developerworks/ (SWT/JFace ~ RCP)
서적


ps. 다른 좋은 학습 방법에 대한 아이디어가 있던가, 좋은 학습 컨텐츠를 발견한다면, 알려주면 감사하겠다.
신고

티스토리 툴바