Eclipse Lab : 팀 블로그

p2

이클립스가 번들들을 설치, 업데이트 또는 관리를 할 때 사용하는 프로비져닝 플랫폼을 P2라고 합니다. 근본적으로, P2는 이클립스 또는 에퀴녹스 기반의 어플리케이션을 프로비져닝하고 관리하는 기술입니다.

Agent

클라이언트에 설치된 프로비져닝 인프라는 주로 Agent라고 언급됩니다. 에이전트는 자기자신이나 다른 프로필을 관리할 수 있습니다. 에이전트는 이클립스 시스템과 별도로 작동할 수 있으며, 다른 이클립스 시스템에 임베딩된 형태일 수도 있습니다. 에이전트는 필요한 경우 여러 프로필을 관리할 수있으며, 반대로 한 시스템이 여러개의 에이전트를 가질수도 있습니다. *P2 에이전트*라고하는 것은 실제로 존재하지 않습니다. P2란 모듈일 뿐이기 때입니다. 임베디딩 시스템이나, 데스크탑 또는 서버에서 P2 에이전트를 사용할 때 각기 다른 모듈이 사용됩니다.

Artifact

아티팩트들은 설치되거나 관리될 실제 컨텐츠를 말합니다. 번들의 JAR파일 또는 실행파일이 대표적인 아티팩트입니다.

Artifact Repository

아티팩트들을 담고 있는 리포지터리를 의미합니다.

Director

디랙터란 Planner와 Engine에서 일어나는 일들에 대한 상위 수준 API입니다. 즉, 디렉터는 플래너에게 프로비져닝 작업들을 수행하게끔 명령을 내리고, 그 결과를 엔진에게 전달하고 적용하게 하여, 필요한 프로비져닝 작업을 수행하게 합니다.

엔진

엔진은 디렉터가 결정한 필요한 프로비져닝 오퍼레이션들을 실제로 수행할 책임을 갖습니다. 디렉터의 주 작업의 주제가 메타데이터인 반면, 엔진의 관심사는 디렉터가 선정한 IU(Installation Unit)들에 포함된 아티팩트 및 구성 정보입니다. 엔진은 필요한 아티팩트를 필요한 위치에서 사용할 수 있도록 리포지터리 및 전송 매커니즘에 협조하게 됩니다.

이클립스 위키에서 엔진 보기

가비지 컬렉션

알려진 루트로 부터 접근성 추적을 통하여, 불필요한 리포지터리의 요소(메타데이터와 아티팩트)들은 수집되어 파기될 수 있습니다. 예를 들어, 에이전트에 의해 관리되는 모든 프로필들은 프로비져닝 에이전트가 직접적으로 관심을 갖는 모든 IU들을 식별할 수 있습니다. 마찬가지로 IU역시 프로필을 실행하기 위해 필요한 아티팩트들을 식별할 수 있습니다. 전이 목록에 포함되지 않은 IU나 아티팩트들은 쓰레기로 취급되며 수집됩니다.

Installation Unit(IU)

IU는 설치될 것들에 대한 정보를 담은 *메타데이터* 이며, 실제로 설치되는 것들을 의미하지 않습니다. 따라서, 번들은 IU가 아니고, 단지 번들의 이름, 버전, 캐퍼빌리티, 디펜던시 등등을 담은 디스크립션입니다. 번들의 JAR는 아티팩트입니다.

이클립스 위키에서 IU 보기

메타데이터 리포지터리

IU들을 담고 있는 메타데이터 리포지터리.

미러링

분산의 기본 오퍼레이션은 미러링입니다.

Phase

프로비져닝 오퍼레이션은 보통 여러 과정(페이즈)에 걸쳐 특정작업을 수행하던 중 일어납니다. 각 과정(Phase)마다 특정한 종류의 활동이 일어납니다. 구성 단계(Configure Phase)에 런타임 시스템과 접점(Touchpoint)의 상태에 따라, 동적으로 다양한 아티팩트를 필요로하게 될 것이고, 그에 따라 동적으로 Fetch Phrase가 수행될 것입니다.

플래너

플래너는 주어진 프로필을 요청받은대로 재 구성하는데 필요한 작업들을 결정합니다. 다시 말해, 프로필의 현재 상태와 목표 상태, 그리고 메타데이터(가용한 IU들에 대한 정보를 담은)를 이용하여 프로비져닝 오퍼레이션들이 담긴 리스트를 만들어 냅니다. (예: 인스톨, 업데이트 또는 언인스톨).

Touchpoint

P2에서 터치포인트는 P2 프로비져닝 시스템과 특정 런타임 및 관리 시스템을 통합하는 임무를 가지며, 엔진의 일부입니다. 예를 들어 이클립스 터치포인트는 에퀴녹스 스토어를 이해하고, 번들을 관리합니다. 다른 플랫폼은 다른 네이티브 터치포인트 구현을 이용하여 통합합니다. 더 다양한 터치포인트의 예제를 보려면 이곳(영문)을 클릭하십시오.

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

검색

이클립스는 세상에서 가장 커다란 오픈 프로젝트이며, 따라서 방대한 양의 좋은 문서들이 모두 공개되어 있습니다. 좋은 검색 습관을 갖는 것 만으로도, 당신의 생산성을 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를 선택하면 이 익스텐젼 포인트를 어떻게 사용하는지 알 수 있다. (우선 용의자 플러그인들을 디펜던시에 넣어둘 것)

관련 링크들

• SWT 스니펫 : http://www.eclipse.org/swt/snippets/
• JFace 스니펫 : http://wiki.eclipse.org/index.php/JFaceSnippets
• 이클립스 공싱 FAQ : http://wiki.eclipse.org/The_Official_Eclipse_FAQs
• 이클립스 뉴스 그룹 (웹) : http://www.eclipse.org/forums/
• 이클립스 뉴스 그룹 (NNTP) : news.eclipse.org (웹에서 사전 등록 필요)
• 이클립스 WIKI : http://wiki.eclipse.org/
• 이클립스 리소스 : http://eclipse.org/resources/

어댑터 패턴

어댑터 패턴의 기본 전략 중 하나는, 한 객체가 특정한 영역에서만 의미를 갖는 기능집합을 요구 받을 때, 원래의 객체로 부터 분리된 어댑터 객체에게 그 임무들을 위임하는 것입니다. 이렇게 함으로써, 객체는 본래의 간결함을 유지 할 수 있으며, 개발자는 본인이 개발하지 않은 컴포넌트에 대해서도, 다른 영역에 참가시키는 것이 가능합니다.

기능영역 -> 컴포넌트: getAdapter();
컴포넌트 -> 컴포넌트: 어댑터 생성
컴포넌트 --> 기능영역: adapter
기능영역 -> 기능영역: 쓰임새 수행

일반적으로 어댑터 질의는 그림처럼 IAdaptable 인터페이스의 getAdapter(Class) 메소드를 통하여 이루어집니다. 하지만, 이 경우에, 어댑터 질의에 응답하는 주체가 객체 그 자체가 되기 때문에, 어댑터가 추가되거나 변경될 때 마다, 객체의 코드가 변경되어야 합니다. 이 경우엔 유연한 협력이나, 블라인드 확장(원래의 컴포넌트가 어떻게 구현되었는지 전혀 모르는 상태에서 기능을 확장시키는 것)이 불가능 합니다. 그러나 서로 모르는 사람들이 가장 많이 참여하는 프로젝트인 이클립스에서는, 이러한 상황이 매우 빈번하게 일어납니다. 이 문서는 모델과 어댑터간의 디커플링을 달성 하는 방법과 원리를 설명합니다.

어댑터 질의를 플랫폼에 위임

이런 문제를 해결하기 위해서 이클립스에서는 어댑터 질의를 플랫폼에게 위임하는 전략을 사용합니다.

기능영역 -> 컴포넌트: getAdapter()
컴포넌트 -> 어댑터매니저: 위임
어댑터매니저 -> 확장점: 팩토리 찾기
확장점 -> 확장점: 확장 탐색
확장점 -> 어댑터팩토리 : 생성
어댑터팩토리 -> 어댑터팩토리: 어댑터 생성
어댑터팩토리 --> 컴포넌트: adapter
컴포넌트 --> 기능영역: 쿼리 응답

이클립스에서 어댑터블한 객체들은 다음과 같은 기본 구현을 가지고 있습니다.

public Object getAdapter(Class adapterType){
	...
	return Platform.getAdapterManager().getAdpater(this, adapterType);
}

두 번 째 줄에서 보이는 바와 같이 이 객체는 어댑터 질의를 Platform에게 위임시킵니다. 따라서, 개발자는 플랫폼에 어댑터 공급 방법을 알려줌으로써, 원래 객체를 수정하지 않고도 어댑터를 추가 공급할 수 있습니다. 이렇게 어댑터를 추가적으로 공급하는데 쓰이는 확장점이 바로 런타임 어댑터 (확장점ID: org.eclipse.core.runtime.adapters) 입니다. 이 확장점은 특정한 타입의 객체에 대해, IAdapterFactory를 등록할 수 있게 해 줍니다. 마찬가지로 여러분이 만든 컴포넌트도 런타임 어댑터를 지원하려면, getAdapter()의 마지막 부분에 마찬가지의 코드를 삽입해야 합니다.

어댑터 팩토리

public interface IAdapterFactory {
	public Object getAdapter(Object adaptableObject, Class adapterType);
	public Class[] getAdapterList();
}

어댑터 팩토리는 위와 같은 메소드 구성을 가집니다. getAdapterList()는 이 어댑터 팩토리가 어떠한 종류의 어댑터 질의를 처리 할 수 있는지를 나타내고, getAdapter()는 실제로 어댑터를 만들어 플랫폼에 제출하는 역할을 합니다. 확장점 정의에보면, 이미 가능한 어댑터 종류에 대한 노드들이 있는데도 불구하고 구현 클래스도 질의를 받는 인터페이스가 있는 이유는, 확장점 뿐만 아니라, 프로그래밍으로도 어댑터를 등록할 수 있게 하기 위해서 입니다.

정리

하는 김에 같이 줏어먹기

Platform.getAdatper(...) 는 현재 활성화된 플러그인들 중에서만 런타임 어댑터 팩토리를 찾아내어 작동합니다. 만약 모든 플러그인과 연동되게 하려면, loadAdpater(...)를 사용해야 합니다. 이 경우, 어댑터 질의 과정중에 다른 플러그인이 활성화 될 수도 있다는 점을 염두에 둬야합니다.

Core Expression

만약 코어 익스프레션에서 adapter 노드를 사용한 경우에, 런타임 어댑터로 등록된 어댑터들만 리턴값이 넘어옵니다. 주의하세요.

Job

Job은 Job Manager에 의해 스케쥴 되고 실행 될 수 있는 작업 단위이다. 하지만 라이프 싸이클이 작업 주기에 한정되지는 않는다. Job이 한 번 완료되고 난 후에, 다시 스케쥴 될 수도 있다.

Job의 기본 사용법

1. Job을 상속 받아 적절한 작업을 기술 한다.
2. 해당 Job의 인스턴스에 schedule()을 호출하여 작업을 스케쥴 한다.
   

Job job = new MyJob("테스트 작업");
job.schedule();

Job은 현재 동작을 가리키는 상태를 가진다. Job이 처음 만들어졌을 때 상태는 NONE이 된다. 실행을 위해 스케쥴 되면, WAITING 상태가 되며, 수행중에는 RUNNING이 된다. 수행이 완료되거나 취소 되면 다시 NONE상태가 된다.

Job은 SLEEPING 상태로도 진입이 가능한다, 사용자가 Job.sleep()을 호출하거나, Job.schedule(delay)의 형태로 지연시간을 갖고 스케쥴 된 경우 이 상태가 된다. WAITING 상태인 Job들만 SLEEPING 상태로 넘어갈 수 있다. 이 Job들은 Job.wakeUp()으로 깨울 수 있으며 WAITING 상태로 돌아간다.

Job들은 우선순위를 가질 수 있지만, 높은 우선순위가 낮은 우선순위보다 먼저 수행된다는 보증을 가지고 있지는 않다. 

schedule

스케쥴 메소드는 현재 상태에 따라 다음과 같이 작동한다:

• NONE - 상태가 없는 경우: 스케쥴 된다
• WATING - 스케쥴 되었지만 아직 실행되지 않은 경우: 아무일도 하지 않음
• RUNNING - 실행중인 경우: 수행이 완료 된 후, 다시 스케쥴 됨, 이 상태에서 다시 스케쥴이 오더라도 한 번만 스케쥴 된다.

Job Manager

Job Manager는 Job들에 대해 스케쥴링, 쿼링, 관리 및 록을 제공하며, 다음과 같은 서비스를 공급한다:

• 대기중(WAITING)인 Job들이 실행 될 수 있게금, 큐를 관리한다.
• Job Family 라고 불리는 작업 그룹을 관리하도록 해 준다.
• 리스너들이 잡의 진행상황을 통보 받을 수 익도록 해 준다.
• Job이나 Job Family가 끝나기를 기다리는 클라이언트에게 피드백을 공급한다.

Schedule Rule

스케쥴 룰은 Job이 스케쥴 될 때 함께 JobManager 에 선포되어 효력을 발휘하고, 잡이 끝나면, 해당 잡이 제공했던 스케쥴 룰의 효력도 끝난다. Job은 스케쥴링 룰을 가질 수도 있고, 가지지 않을 수도 있다. 스케쥴링 룰이 없다면, 아무때에나 스케쥴 되고 수행 될 수 있음을 의미한다.

스케쥴 룰은 일반적으로, 특정한 리소스에 대해 배타적으로 작업들이 수행될 되어야 할 때 사용한다. Job.setRule(IScheduleRule)을 통해 Job의 스케쥴링 규칙을 정해 줄 수 있다. 스케쥴링 룰은 서로 포함 또는 배제라는 관계를 갖는데 각각 contains(IScheduleRule)과 isConflicting(IScheduleRule)로 구현된다.

• contains: 한 스케쥴 룰이 다른 스케쥴 룰을 포함한다는 것은 - 편의상 포함되는 룰을 자식, 포함하는 룰을 부모라 한다 - 부모 룰이 선포되어 운영되는 도중, 자식 룰이 함께 선포될 수 있음을 의미한다. 일반적으로 룰이 다른 룰에 대해 아는 것이 없을 경우에는 반드시 false를 리턴해야 한다.
  
• conflict: 두 스케쥴링 룰은 동시에 선포될 수 없으므로, 충돌하는 스케쥴 룰을 가진 Job들은, 먼저 수행된 Job이 끝나 해당 스케쥴링 룰의 운영이 끝난 다음 스케쥴 된다.
  

• 특정 리소스에 대해 록을 제공하는 룰
  ResourcesPlugin.getWorkspace().getRuleFactory().createRule(IResource)
  이는 매우 유용하면서 필수적인 도구이다. 이를 이용하여, 적절한 lock을 확보하지 않는다면, SVN이나 CVS 플러그인 들이 끔찍한 반응을 해 올 수도 있다.
  

IFile testFile = ....
// testFile 을 동시에 두 작업이 접근하지 못하도록 하는 룰
IScheduleRule fileAccessRule =
    ResourcesPlugin.getWorkspace().getRuleFactory().createRule(testFile);

Job job = new HandleFileJob();
job.setRule(fileAccessRule);

job.schedule();

// 이클립스 AutoBuildJob의 생성자
AutoBuildJob(Workspace workspace) {
	super(Messages.events_building_0);
	
	// 워크스페이스 루트 자체를 룰로 지정한다.
	// 빌드가 끝나기 전까지 어떤 다른 Job도 워크스페이스에 접근 할 수 없다.
	setRule(workspace.getRoot());

	setPriority(BUILD);
	isAutoBuilding = workspace.isAutoBuilding();
	this.workspace = workspace;
	this.preferences.addPropertyChangeListener(this);
}

Job의 종류

작업이 진행되는 배경적 특성에 따라 몇 가지 유용한 부모 Job 클래스들이 공급된다.

• WorkspaceJob: 워크스페이스 잡은, 잡이 종료될 때 까지 발생하는 모든 리소스 변경 통지를 멈춰두었다 작업이 완료된후 일시 통보하는 기능을 가진다. 만약, 수많은 파일을 일괄적으로 변조하는 작업을 수행할 때 이러한 조치를 취하지 않는다면, 자동 빌딩이 끝 없이 스케쥴되는 골치 아픈 광경을 볼 수 있게 될 것이다.
  
• WorkbenchJob: 원래는 워크벤치가 소멸되거나 완전히 준비되기 전에 작업이 수행되는 것을 방지하기 위해 고안 되었지만, 작업이 UI수정을 포함할 때도 많이 쓰인다. UI 스레드와 동기화되어 실행되기 때문이다. - 워크밴치가 시작 되자 마자 무언가가 실행되게 하고 싶다면, 이를 상속하는 것이 좋다.

Job Family

Job 들은 필요에 따라 특정 분류그룹을 가질 수 있으며, 여러 그룹에 속할 수도 있다. public boolean belongsTo(Object family)를 오버라이드 하여, 특정 Job이 어떤 패밀리에 속하는지 기술 할 수 있다. Job.getJobManager()는 패밀리 객체를 통한 Job 찾기등의 API를 공급하기 때문에, 각 Job들이 스캐쥴되거나 실행될때마다 같은 그룹에 속한 Job의 상태에 따라 반응하게 하는 것이 가능하다. 예를 들어, 여러번의 업데이트 Job 중 가장 마지막에 스케쥴 된 Job만 실행되게 할 수 있다.