3.0 메커니즘 및 API를 채택할 때 필요한 변경사항

이 섹션에서는 3.0 메커니즘 및 API를 채택하도록 2.1 플러그인을 변경하려는 경우 필요한 변경사항에 대해 설명합니다.

org.eclipse.core.runtime.compatibility 제거

Eclipse 3.0 런타임은 상당히 다릅니다. 기본적인 구현이 OSGi 프레임워크 스펙을 기초로 합니다. Eclipse 3.0 런타임에는 2.1 API를 유지보수하는 호환성 계층(org.eclipse.core.runtime.compatibility 플러그인에서)이 포함됩니다. 추가 성능 및 기능에도 관심이 있는 플러그인 개발자는 3.0 API를 채택하고 호환성 계층에서 종속성을 제거할 것을 고려해야 합니다. 호환성 코드는 세 곳에서 표시됩니다.

아래의 텍스트는 호환성 목적과 플러그인 갱신 방법 안내를 위한 클래스 및 메소드에 관한 세부사항을 제공합니다.

플러그인 및 번들

Eclipse 런타임은 두 부분으로 리팩토링되었습니다. 클래스로딩 및 전제조건 관리와 확장/확장점 관리입니다. 이러한 분할로 클래스로딩 및 전제조건 관리에 대한 OSGi 프레임워크 스펙을 자연스럽게/한결같이 채택할 수 있습니다. 이로서 동적 플러그인 설치/설치 제거/갱신에서 보안 및 구성 가능성 증가에 이르기까지 런타임에서 광범위한 새 기능을 사용할 수 있습니다.

계속해서 플러그인에 대해 이야기하고 있는데, 새 런타임에서는 플러그인이 실제로 번들에 일부 확장 및 확장점을 더한 것입니다. 번들이라는 용어는 OSGi 프레임워크 스펙에서 정의되어 있으며 유형 및 자원과 이에 연관되는 번들간 전제조건 정보의 콜렉션을 말합니다. 확장 레지스트리는 플러그인 레지스트리의 새 양식으로 확장 및 확장점 정보만 자세히 설명합니다. 대체로 확장 레지스트리 API는 관련된 플러그인 레지스트리 API와 같습니다(자세한 정보는 레지스트리를 참조하십시오).

Eclipse 2.x 런타임에서, 플러그인 오브젝트는 여러 개의 역할 및 책임을 가지고 있습니다.

Eclipse 3.0 런타임 그림에서, 이 역할과 책임은 별도의 오브젝트로 팩터링됩니다.

번들
번들은 모듈 방식의 OSGi 장치입니다. 번들당 하나의 클래스 로더가 있고 Eclipse와 유사한 번들간 클래스 로딩 종속성 그래프를 생성할 수 있습니다. 번들은 시작 및 중지와, 관심있는 부분에 대한 OSGi 프레임워크 브로드캐스트 번들 관련 이벤트(예: 설치, 분석, 시작, 중지 설치 제거...)의 라이프사이클을 가지고 있습니다. Eclipse 플러그인 클래스와는 달리, OSGi 번들 클래스는 확장 가능하지 않습니다. 즉, 개발자는 자신의 번들 클래스를 정의할 기회를 갖지 못합니다.
BundleActivator
BundleActivator는 OSGi 프레임워크로 정의된 인터페이스입니다. 각각의 번들은 플러그인이 해당되는 플러그인 클래스를 정의할 수 있는 것처럼 번들 활성화기 클래스를 정의할 수 있습니다. 지정된 클래스는 프레임워크에 의해 인스턴스가 작성되고 start()stop() 라이프사이클 처리를 구현하는 데 사용됩니다. 그러나 이 라이프사이클 처리 속성에 주요한 차이점이 있습니다. Eclipse에서는 플러그인 클래스가 초기화 및 등록 둘 다를 수행하도록 하는 것이 일반적입니다(권장사항은 아니지만). OSGi에서 활성화기만 등록을 수행해야 합니다. BundleActivator.start()에서 많은 양의 초기화(또는 다른 작업)를 수행하면 시스템 활성 상태를 위협하게 됩니다.
BundleContext
BundleContext는 개인 번들에 일반적인 시스템 기능을 노출하기 위한 OSGi 메커니즘입니다. 각 번들에는 시스템 기능에 액세스하기 위해 사용할 수 있는 BundleContext의 고유한 개인 인스턴스가 있습니다(예: 시스템에 있는 모든 번들을 발견하기 위한 getBundles()).
플러그인
플러그인플러그인 오브젝트가 더 이상 필요하지 않거나 런타임에 의해 관리되므로 다양한 메소드가 폐기되었다는 점을 제외하고 원래 Eclipse 플러그인 클래스와 아주 유사합니다. 유용한 기능 및 메커니즘의 호스트를 제공하는 편리한 메커니즘이지만 절대적으로 반드시 필요하지는 않습니다. 이 메커니즘에서 제공되는 많은 기능은 런타임에서 플랫폼 클래스에서도 사용할 수 있습니다.

플러그인은 또한 BundleActivator를 구현합니다. 이는 플러그인의 라이프사이클 및 시맨틱을 표시하는 하나의 중심 오브젝트를 가지고 있을 경우의 편리성을 인식합니다. 그러나 이는 오늘날 플러그인에 공통되는, 데이터 구조에 대한 편리한 초기화가 적용되지는 않습니다. 어떤 다른 플러그인에서 클래스를 검증하는 동안 다소 중요하지 않은 클래스가 참조되었으므로 플러그인이 활성화될 수 있다고 충분히 강조할 수 없습니다. 즉, 사용자의 플러그인이 활성화되었다고 해서 해당 기능이 반드시 필요하다는 것을 의미하지는 않기 때문입니다. 또한 다른 BundleActivator 클래스를 정의하는 것은 사용자에게 달려 있으며 정의하지 않을 경우 번들 활성화기를 전혀 가지고 있지 않음을 유의하십시오.

2.x 플러그인 클래스를 Eclipse 3.0으로 이식하는 데 필요한 단계는 클래스가 수행 중인 대상에 따라 다릅니다. 위에 요약된 것처럼, 대부분의 시작 라이프사이클 작업은 다음 카테고리 중 하나에 속합니다.

초기화
데이터 구조 및 모델 초기화는 Plugin.startup()에서 자주 수행됩니다. 본래의/명백한 맵핑은 BundleActivator.start()에서 이를 수행하게 됩니다. 즉 플러그인에서 기능을 수행하지 않습니다. 이는 권장되지 않습니다. 2.x 플러그인에서와 같이, 3.0 플러그인/번들은 다양한 상황에서 여러가지 이유로 시작할 수 있습니다.
Eclipse 2.0의 실제 예제는 이 경우를 보여줍니다. 약 11MB의 코드와 대용량의 데이터를 로딩해야 하는 대형 모델을 초기화한 플러그인이 있습니다. 이 플러그인이 네비게이터에 표시된 프로젝트 아이콘을 특정 마크업으로 작성되어야 하는 지 여부를 발견하기 위해 활성화된 일반 유스 케이스가 있습니다. 이 테스트에서는 startup()에서 초기화를 수행할 필요가 없었지만 이미 모든 유스 케이스에 있는 모든 사용자는 이러한 초기화에 기대로 인해 메모리 및 시간 불이익을 입었습니다.
대체 방식은 이전 방식처럼 초기화를 수행하는 것입니다. 예를 들어, 플러그인/번들이 활성화될 때 모델을 초기화하기 보다는 실제로 필요할 때(예: 중앙 집중화된 모델 액세서 메소드에서) 초기화하십시오. 대부분의 유스 케이스에서 이는 시간상 거의 같지만 다른 시나리오의 경우에는 이 접근 방식이 초기화를 지연시킵니다. 2.1 플러그인을 이식하는 중에도 사용되는 초기화 전략을 다시 고려할 시간을 가지십시오.
등록
플러그인 시작은 리스너, 서비스 등을 등록하고 배경 처리 스레드(예: 소켓에서 청취)를 시작하기 편리한 시점입니다. Plugin.start()는 이 작업을 수행하기에 적절한 공간일 수 있습니다. 일부 다른 트리거가 발생할 때까지(예: 특정 기능 또는 데이터 요소 사용) 지연하도록 할 수도 있습니다.
플러그인 글로벌 데이터
플러그인 클래스는 계속 이 역할을 수행할 수 있습니다. 기본적인 문제는 플러그인 오브젝트가 더 이상 시스템 관리 목록을 통해 글로벌로 액세스할 수 없다는 것입니다. Eclipse 2.x에서는 플러그인 레지스트리를 통해 플러그인의 플러그인 오브젝트를 발견할 수 있었습니다. 이는 더 이상 가능하지 않습니다. 대부분의 상황에서 이 유형의 액세스는 필요하지 않습니다. 레지스트리를 통해 액세스한 플러그인은 도메인 특정 메소드를 호출하는 것보다 오히려 더 일반적으로 일반 플러그인으로서 사용됩니다. 해당되는 번들 오브젝트에 액세스하고 조작하여 해당 레벨의 기능을 가질 수 있습니다.

레지스트리 및 플러그인 모델

새 런타임에서는 플러그인을 실행하는 데 필요하며 플러그인 확장 및 확장점에 관련되는 정보 및 구조 사이에 구분되어 있습니다. 전자는 OSGi 프레임워크 스펙에 의해 정의 및 관리되고 후자는 Eclipse 특정 개념으로 Eclipse 런타임 코드로 추가됩니다. 이에 따라, 원래 플러그인 레지스트리 및 관련 오브젝트가 OSGi 번들 및 Eclipse 확장 레지스트리로 분할되었습니다.

실행 스펙(예: IPluginDescriptor, ILibrary, IPrequisite)을 다루는 IPluginRegistry의 파트가 폐기되고 확장 및 확장점에 관련되는 나머지 파트는 IExtensionRegistry로 이동되었습니다. 게다가 플러그인 레지스트리에 관련되는 이른바 모델 오브젝트도 이제 전체적으로 폐기되었습니다. 이 유형들은 기본적으로 PDE와 같은 도구를 지원하기 위해 런타임에서 제시되고 인스턴스가 작성되었습니다. 불행히도, 필요한 정보 레벨이 런타임의 기능 또는 관심(예: plugin.xml 요소의 행 번호 기억)을 초과하고 결국 런타임 정보의 잠재된 이용자가 자신의 구조를 어떻게든지 유지해야 하는 경우가 종종 있었습니다.

새 런타임에서는 런타임이 제공하는 기능을 다시 평가했으며, 이제는 런타임 실행에 중요하거나 다른 대상에게는 수행하기가 엄청 어려운 기능만 제공합니다. 위에 언급된 것처럼, 플러그인 레지스트리 모델 오브젝트가 폐기되었습니다. 플러그인 구문 분석 API를 가지고 있기 때문입니다. 새 확장 레지스트리는 중요한 확장 관련 정보를 유지보수합니다. 새 상태(org.eclipse.osgi.service.resolver.State 및 일원 참조) 구조가 제시되며 중요한 실행 관련 정보를 조작할 수 있습니다.

NL 단편 구조

Eclipse 3.0에서는 NL 단편 구조가 더 일관성을 유지하도록 갱신되었습니다. 이전에는 plugin.properties와 같은 파일의 변환이 단편에 의해 제공되는 JAR 안에 있는 것으로 가정했습니다. 원래 파일은 관련 호스트 플러그인 루트에서 발견되므로, 더 일관성 있는 위치에서 NL 단편의 루트에 있는 변환된 파일을 갖게 됩니다. 예를 들어,

  org.eclipse.ui.workbench.nl/
     fragment.xml
     plugin_fr.properties
     plugin_pt_BR.properties
     ...
     nl1.jar

여기에서 nl1.jar 파일은 이전에 plugin.properties에 대한 변환을 포함하도록 되어 있었습니다. 이 파일은 이제 단편의 루트에 있으며 JAR이 호스트 플러그인에서 변환 가능 자원(즉, 클래스 로더를 통해 로드되는 파일)의 변환을 포함합니다.

물론 Eclipse 2.1 NL 단편 구조는 계속 Eclipse 3.0에서 실행되는 2.1 호스트 플러그인에 대해 지원됩니다. 그러나 3.0 플러그인에서는 2.1 NL 단편을 사용할 수 없습니다. 단편은 새 구조로 갱신해야 합니다.

API 변경 개요

org.eclipse.core.boot(패키지 org.eclipse.core.boot)

전체 org.eclipse.core.boot 패키지가 폐기되었습니다. BootLoader는 더 이상 시동 및 런타임 사이의 분할을 인식하지 못하므로 org.eclipse.core.runtime.Platform과 병합되었습니다. 사실, org.eclipse.core.boot 플러그인은 구분되어 해당되는 모든 코드가 새 런타임 또는 호환성 계층으로 이동되었습니다.

IPlatformConfiguration은 항상 Eclipse 설치/갱신 컴포넌트에 의해(대해) 정의된 유형이었습니다. 런타임 재구성으로, 이 유형을 적절한 홈으로 보낼 수 있습니다. 이 클래스는 대규모로 변경되지 않은채 유지되며 org.eclipse.update.configurator.IPlatformConfiguration으로 다시 패키징되었습니다.

IPlatformRunnable은 org.eclipse.core.runtime.IPlatformRunnable로 이동되었습니다.

IExtension 및 IExtensionPoint(패키지 org.eclipse.core.runtime)

getDeclaringPlugin() 메소드(두 클래스 모두의)는 확장 또는 확장점을 선언하는 플러그인에 각각 상향 링크를 제공합니다. 새 레지스트리 모델은 플러그인의 실행 측면을 확장/확장점 측면과 분리하고 더 이상 IPluginDescriptors를 포함하지 않습니다. 이 API의 사용자는 IExtensionIExtensionPoint에서 발견되는 새 메소드 getParentIdentifier()를 고려해야 합니다.

ILibrary, IPluginDescriptor, IPluginRegistry 및 IPrerequisite(패키지 org.eclipse.core.runtime)

원래 런타임에서, 플러그인 레지스트리는 런타임 구성의 전체 그림을 유지보수했습니다. Eclipse 3.0에서는 이 그림이 OSGi 프레임워크 및 확장 레지스트리에 걸쳐 분할됩니다. 이에 따라 해당 클래스가 폐기되었습니다. 폐기 주의사항에는 코드 갱신 방법이 자세히 설명되어 있습니다.

플랫폼 및 플러그인(패키지 org.eclipse.core.runtime)

새 런타임에서는 Plugin 오브젝트가 더 이상 런타임에 의해 관리되지 않으므로 플랫폼을 통해 일반적으로 액세스할 수 없습니다. 마찬가지로, 플러그인 레지스트리는 더 이상 존재하지 않거나 플러그인 설명자에 대한 액세스를 제공합니다. 그러나 사용할 수 있는 적절한 대체 메소드가 있으며 이 클래스에서 페기된 메소드의 Javadoc에 자세히 설명되어 있습니다.

org.eclipse.core.runtime.model(패키지 org.eclipse.core.runtime.model)

이 패키지의 모든 유형이 폐기되었습니다. 자세한 정보는 레지스트리 설명을 참조하십시오.

IWorkspaceRunnable 및 IWorkspace.run(패키지 org.eclipse.core.resources)

IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) 메소드의 클라이언트는 이 메소드를 사용한 위치에 다시 방문하여 더 풍부한 IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor) 메소드를 사용할 것을 고려해야 합니다. 이전 IWorkspace.run 메소드는 IWorkspaceRunnable 지속 기간 동안 전체 작업공간에 대한 잠금을 획득합니다. 이는 이 메소드로 수행된 조작이 작업공간을 변경하는 다른 조작과 동시에 실행할 수 없음을 의미합니다. Eclipse 3.0에서, 많은 장기 실행 조작이 배경 스레드로 이동되었으므로, 조작 사이의 충돌 발생 가능성이 확실하게 높아졌습니다. 모달 전경 조작이 장기 실행 배경 조작으로 블록화된 경우, 배경 조작이 완료되거나 조작 중 하나가 취소될 때까지 UI는 블록화됩니다.

제안되는 솔루션은 모든 참조를 이전 IWorkspace.run으로 전환하여 스케줄링 규칙 매개변수와 함께 새 메소드를 사용하는 것입니다. 스케줄링 규칙은 해당 조작에 의해 수행되는 모든 변경사항에 해당되는 규칙을 포함하는 가장 세밀한 규칙이어야 합니다. 조작이 스케줄링 규칙 범위 밖에서 자원을 수정하려고 할 경우 런타임 예외가 발생합니다. 지정된 작업공간 조작에 필요한 정확한 스케줄링 규칙이 지정되어 있지 않으므로, 지정된 프로젝트에 설치된 저장소 제공자에 따라 변경할 수 있습니다. 팩토리 IResourceRuleFactory를 사용하여 resource-changing 조작에 해당되는 스케줄링 규칙을 확보해야 합니다. 원할 경우 MultiRule을 사용하여 여러 개의 자원 규칙을 지정하고 MultiRule.combine 편리 메소드를 사용하여 다양한 resource-changing 조작의 규칙을 결합할 수 있습니다.

잠금이 필요하지 않을 경우, null 스케줄링 규칙을 사용할 수 있습니다. 이로서 실행 프로그램이 작업공간에 있는 모든 자원을 수정할 수 있지만 다른 스레드가 동시에 작업공간을 수정하지 못하도록 방지하지는 못합니다. 작업공간에 대한 단순 변경의 경우 이는 종종 가장 쉬우면서 가장 동시성이 익숙한 솔루션입니다.

IWorkbenchPage(패키지 org.eclipse.ui)

IEditorDescriptor(패키지 org.eclipse.ui)

ISharedImages(패키지 org.eclipse.ui)

IWorkbenchActionConstants(패키지 org.eclipse.ui)

IWorkbenchPreferenceConstants(패키지 org.eclipse.ui)

IExportWizard(패키지 org.eclipse.ui)

IImportWizard(패키지 org.eclipse.ui)

INewWizard(패키지 org.eclipse.ui)

WorkbenchHelp(패키지 org.eclipse.ui.help)

IHelp(패키지 org.eclipse.help)

ITextEditorActionConstants(패키지 org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds(패키지 org.eclipse.ui.texteditor)

BasicTextEditorActionContributor(패키지 org.eclipse.ui.texteditor)

TextEditorActionContributor(패키지 org.eclipse.ui.editors.text)

annotationTypes 확장점(플러그인 org.eclipse.ui.editors)

이제는 어노테이션 유형의 명시적 개념이 있습니다. Annotation.getType() 및 Annotation.setType()을 참조하십시오. 어노테이션 유형은 라이프사이클 중에 변경할 수 있습니다. 새 확장점은 어노테이션 유형 선언 "org.eclipse.ui.editors.annotationTypes"을 위해 추가되었습니다. 어노테이션 유형에는 이름이 있어서 선언된 다른 어노테이션 유형의 하위 유형으로 선언될 수 있습니다. 어노테이션 유형 선언은 "markerType" 및 "markerSeverity" 속성을 사용하여 지정된 유형의 마커와 지정된 심각도가 특정 어노테이션 유형의 어노테이션으로 텍스트 편집기에 표시되도록 지정할 수도 있습니다. "org.eclipse.ui.editors.markerAnnotationSpecification"에서 "markerType" 및 "markerSeverity" 속성은 더 이상 사용되지 않습니다. 마커 어노테이션 스펙은 마커와는 관계가 없게 되므로 이름이 잘못될 수 있습니다. 그러나 이름은 역호환성을 위해 보존됩니다.

AbstractMarkerAnnotationModel의 서브클래스 인스턴스는 마커로부터 작성하는 어노테이션에 대해 자동으로 올바른 어노테이션 유형을 발견하여 설정합니다. 지정된 마커나 지정된 markerType 및 markerSeverity 쌍에 해당되는 어노테이션 유형을 프로그램 방식으로 검색하려면 org.eclipse.ui.texteditor.AnnotationTypeLookup을 사용하십시오.

어노테이션 유형의 계층 구조에 대한 액세스는 IAnnotationAccessExtension이 제공합니다. 지정된 어노테이션 유형에 대해 상위 유형 체인을 가져오고 어노테이션 유형이 다른 어노테이션 유형의 상위 유형인지 확인할 수 있습니다. DefaultMarkerAnnotationAccess는 이 인터페이스를 구현합니다.

markerAnnotationSpecification 확장점(플러그인 org.eclipse.ui.editors)

어노테이션 유형은 연관된 마커 어노테이션 스펙을 찾는 키입니다. 어노테이션 유형은 다른 어노테이션 유형을 확장할 수 있으므로 마커 어노테이션 스펙 사이에는 내재된 관계가 있습니다. 따라서 지정된 어노테이션 유형에 대한 마커 어노테이션 스펙은 지정된 어노테이션 유형의 상위 유형에 대해 제공된 마커 어노테이션 스펙에 의해 완료됩니다. 따라서 마커 어노테이션 스펙은 이전에 필요했으므로 완료할 필요가 없습니다. 마커 어노테이션 스펙은 AnnotationPreferences에 의해 검색됩니다. org.eclipse.ui.texteditor.AnnotationPreferenceLookup을 사용하여, 어노테이션 상위 유형 체인에 따라 환경 설정 완료를 투명하게 수행하는 지정된 어노테이션 유형의 어노테이션 환경 설정을 검색할 수 있습니다.

마커 어노테이션 스펙은 세로 눈금자에서 지정된 어노테이션 유형의 사용자 정의 모양 정의가 허용되도록 세 개의 추가 속성으로 확장되었습니다. 이 속성은 "icon", "symbolicIcon" 및 "annotationImageProvider"입니다. "icon"의 값은 아이콘 이미지를 포함하는 파일의 경로입니다. "symbolicIcon"의 값은 "error", "warning", "info", "task", "bookmark" 중 하나가 될 수 있습니다. "symbolicIcon" 속성은 오류, 경고, 정보, 타스크 및 책갈피를 각각 표시하기 위해 플랫폼이 사용하는 동일 이미지로 어노테이션을 묘사해야 함을 플랫폼에 지시하는 데 사용됩니다. "annotationImageProvider"의 값은 전체 사용자 정의 어노테이션 프리젠테이션에 대해 허용되는 org.eclipse.ui.texteditor.IAnnotationImageProvider를 구현하는 클래스입니다.

세로 눈금자는 해당되는 연관 IAnnotationAccess/IAnnotationAccessExtension을 사용하여 어노테이션을 그립니다. 세로 눈금자는 Annotation.paint를 더 이상 호출하지 않습니다. 일반적으로, 어노테이션은 더 이상 자체를 그리도록 제안되지 않습니다. 결국 어노테이션이 UI와 관계가 없도록 하기 위해 "paint" 및 "getLayer" 메소드가 폐기되었습니다. DefaultMarkerAnnotationAccess는 IAnnotationAccess/IAnnotationAccessExtension의 기본 구현으로 서비스를 제공합니다. DefaultMarkerAnnotationAccess는 어노테이션 페인팅을 위해 다음 전략을 구현합니다. 전략: 어노테이션이 IAnnotationPresentation을 구현할 경우 IAnnotationPresentation.paint가 호출됩니다. 그렇지 않으면 어노테이션 이미지 제공자를 어노테이션 환경 설정에서 찾습니다. 어노테이션 이미지 제공자는 지정된 경우에 엔클로징 마커 어노테이션 스펙을 정의하는 플러그인이 이미 로드된 경우에만 사용할 수 있습니다. 어노테이션 이미지 제공자가 있을 경우에는 호출이 이 제공자로 전달됩니다. 그렇지 않으면 지정된 "icon"을 찾습니다. "symbolicIcon"은 최종 대체로 사용됩니다. 어노테이션 그리기에는 어노테이션 프리젠테이션 계층이 관련됩니다. DefaultMarkerAnnotationAccess는 다음 전략을 사용하여 프리젠테이션 계층을 찾습니다. 전략: 어노테이션 환경 설정이 프리젠테이션 계층을 지정할 경우, 지정된 계층이 사용됩니다. 계층이 없는데 어노테이션이 IAnnotationPresentation을 구현할 경우에는 IAnnotationPresentation.getLayer가 사용되고 그렇지 않으면 기본 프리젠테이션 계층(0)이 리턴됩니다.

annotationTypes 확장점으로 이주(플러그인 org.eclipse.ui.editors)

org.eclipse.ui.editors 플러그인에 의해 다음 어노테이션 유형이 선언됩니다.

   <extension point="org.eclipse.ui.editors.annotationTypes">
      <type
         name="org.eclipse.ui.workbench.texteditor.error"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="2">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.warning"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="1">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.info"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="0">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.task"
         markerType="org.eclipse.core.resources.taskmarker">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.bookmark"
         markerType="org.eclipse.core.resources.bookmark">
      </type>
   </extension>   

정의된 markerAnnotationSpecification 확장은 더 이상 "markerType" 및 "markerSeverity" 속성을 제공하지 않습니다. 이 확장은 해당되는 값을 사용하여 "symbolicIcon" 속성을 정의합니다. 따라서 MarkerAnnotation.paint 및 MarkerAnnotation.getLayer는 더 이상 호출되지 않습니다(즉, 이 메소드를 대체해도 효과가 없습니다). 영향을 받는 클라이언트는 IAnnotationPresentation를 구현해야 합니다.

ILaunchConfigurationType(패키지 org.eclipse.debug.core)

3.0에는 확장 가능한 실행 모드가 도입되어 있으므로, 하나의 실행 구성 유형에 대해 여러 개의 실행 위임이 존재할 수 있습니다. 3.0 이전 릴리스는 실행 구성 유형마다 하나의 실행 위임만 지원했습니다. 메소드 ILaunchConfigurationType.getDelegate()는 이제 사용되지 않습니다. 메소드 getDelegate(String mode)를 대신 사용하여 특정 실행 모드에 해당되는 실행 위임을 검색해야 합니다. 폐기된 메소드는 run 모드에 해당되는 실행 위임을 리턴하도록 변경되었습니다.

ILaunchConfigurationTab 및 ILaunchConfigurationTabGroup(패키지 org.eclipse.debug.ui)

실행이 완료될 때 실행 탭 그룹 및 실행 탭에 더 이상 알리지 않습니다. ILaunchConfigurationTabILaunchConfigurationTabGroup 인터페이스에서 메소드 launched(ILaunch)가 폐기되어 더 이상 호출되지 않습니다. 실행 기능에 대해 이 메소드에 의존할 경우 항상 문제점이 발생했습니다. 실행 대화 상자에서 실행을 수행할 경우에만 탭이 존재하기 때문입니다. 또한 배경 실행 도입으로, 이 메소드는 더 이상 호출할 수 없습니다. 결과로 생성되는 실행 오브젝트가 존재하기 전에 실행 대화 상자가 닫히기 때문입니다.

ILaunchConfigurationTab 및 AbstractLaunchConfigurationTab(패키지 org.eclipse.debug.ui)

ILaunchConfigurationTab 인터페이스에 두 개의 메소드(activated 및 deactivated)가 추가되었습니다. 이 새로운 라이프사이클 메소드는 각각 탭에 진입할 경우와 나갈 경우에 호출됩니다. 디버그 플러그인(AbstractLaunchConfigurationTab)이 제공한 추상 클래스를 서브클래스화하는 ILaunchConfigurationTab의 기존 구현은 메소드가 추상 클래스에서 구현되므로 2진 호환 가능합니다.

이전 릴리스에서는 탭이 활성화될 때 initializeFrom 메시지가 송신되고 비활성화될 때 performApply 메시지가 송신되었습니다. 이 방식에서, 실행 구성 탭 프레임워크는 실행 구성을 통해 탭 사이의 통신을 제공했습니다(탭에서 나갈 때 현재 속성 값으로 구성을 갱신하고 새로 탭에 들어갈 때 갱신하여). 하지만 많은 탭이 탭 사이의 통신을 수행하지 않으므로 이는 비효율적입니다. 또한 활성화되는 탭과 처음으로 선택된 실행 구성을 표시하는 탭 사이에 구별할 방법이 없었습니다. 새로 추가된 메소드를 사용하여 탭은 활성화 및 초기화 사이에 구별하고 비활성화 및 현재 값 저장 사이에 구별할 수 있습니다.

추상 탭이 제공하는 activated의 기본 구현은 initializeFrom을 호출합니다. 그리고 deactivated의 기본 구현은 performApply를 호출합니다. 새 API를 이용하려는 탭은 필요에 따라 이 메소드를 대체해야 합니다. 일반적으로, 탭 사이의 통신을 수행하지 않는 탭의 경우 권장되는 접근 방식은 아무 것도 수행하지 않도록 이 메소드를 다시 구현하는 것입니다.

launchConfigurationTabGroup 확장점 유형(패키지 org.eclipse.debug.ui)

이전 릴리스에서는 실행 구성에서 실행 구성 속성 ATTR_TARGET_DEBUG_PERSPECTIVEATTR_TARGET_RUN_PERSPECTIVE를 통해 Perspective 전환을 지정했습니다. 3.0에는 확장 가능 실행 모드가 추가되었으므로 이 접근 방식은 더 이상 확장하지 않습니다. Perspective 전환은 이제 실행 구성 유형이 지원하는 실행 모드마다 실행 구성 유형을 기초로 지정됩니다. 특정 실행 모드에 해당되는 실행 구성 유형과 연관되는 Perspective를 설정하고 가져오기 위해 DebugUITools에 API가 추가되었습니다.

또한 선택적 launchMode 요소가 launchConfigurationTabGroup 확장점에 추가되어, 제공된 탭 구성이 실행 구성 유형 및 모드에 대한 기본 Perspective를 지정할 수 있습니다.

Eclipse 사용자 인터페이스를 통해, 사용자는 실행 구성 대화 상자를 열고 트리(개별 구성이 아닌)에서 실행 구성 유형 노드를 선택하여 실행 구성 유형과 연관되는 Perspective를 편집할 수 있습니다. 사용자가 각각의 지원되는 실행 모드에서 Perspective를 설정할 수 있는 탭이 표시됩니다.

[JDT 전용] IVMRunner(패키지 org.eclipse.jdt.launching)

환경 변수 설정 및 검색을 지원하기 위해 두 개의 메소드가 VMRunnerConfiguration 클래스에 추가되었습니다. IVMRunner 구현자는 VMRunnerConfiguration.getEnvironment()를 호출하고 해당 환경을 실행된 JVM으로 전달해야 합니다. DebugPlugin.exec(String[] cmdLine, File workingDirectory)를 사용하는 클라이언트는 대신 DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp)를 호출하여 이를 수행할 수 있습니다. getEnvironment()를 통해 결과를 전달하는 것만으로 충분합니다.

[JDT 전용] VMRunnerConfiguration 및 Bootstrap 클래스(패키지 org.eclipse.jdt.launching)

이전 릴리스에서는 VMRunnerConfiguration에 시동 경로를 설명하기 위한 하나의 속성이 있었습니다. 속성은 -Xbootclasspath 인수에 지정될 String 콜렉션입니다. 시동 경로 앞뒤에 추가할 수 있도록 허용하는 JVM을 지원하기 위해 VMRunnerConfiguration에 세 개의 새 속성이 추가되었습니다. 추가된 새 메소드/속성은 다음과 같습니다.

이전 속성인 getBootClassPath()는 계속 존재하며 세 개의 새 속성에 해당되는 전체 경로를 포함합니다. 그러나 새 시동 경로 옵션을 지원하는 VMRunners는 새 속성을 이용해야 합니다.

[JDT 전용] 작업 중인 사본에 대한 지원 개선(패키지 org.eclipse.jdt.core)

복사 기능 작업을 수행 중인 Java 모델은 3.0에서 확실한 기능성 증가를 제공하기 위해 다시 작업했습니다. 3.0 이전에는 컴파일 단위의 개인 작업 사본을 작성할 수 있었습니다. 작업 중인 사본을 변경할 수 있었으며 나중에 확약했습니다. Java 모델의 나머지 컨텍스트에서 제한된 작업 사본 분석을 위한 지원이 있었습니다. 그러나 한 번에 작업 사본 중 두 개 이상을 분석에 고려할 수 있는 방법은 없었습니다.

3.0에서의 변경사항으로 컴파일 단위의 작업 사본 세트를 작성 및 관리하고 세트에 있는 모든 작업 사본 존재에 대해 분석을 수행할 수 있게 되었습니다. 예를 들어, 이제는 JDT 리팩토링 같은 클라이언트는 수정 중으로 간주하고 있는 하나 이상의 컴파일 단위에 대한 작업 사본을 작성한 후 작업 사본 사이의 유형 참조를 분석할 수 있습니다. 이전에는 컴파일 단위 작업 사본에 대한 변경사항이 확약된 후에만 가능했습니다.

Java 모델 API는 이와 같은 개선된 지원을 추가하기 위해 두 가지 방법으로 변경되었습니다.

(1) 이전에 IWorkingCopy에서 발견되었고 ICompilationUnit에 의해 상속된 기능은 ICompilationUnit에 통합되었습니다. IWorkingCopy 인터페이스는 이 하나의 공간에서만 사용되었지만 근거없이 더 일반화되어 필요하게 되었습니다. 이 변경으로 API가 단순화되었습니다. IWorkingCopy는 폐기되었습니다. API에서 IWorkingCopy가 매개변수 또는 결과 유형으로 사용되는 다른 공간도 폐기되었습니다. 대체 API 메소드에서는 IWorkingCopy 대신 ICompilationUnit를 언급합니다.

(2) IBufferFactory 인터페이스가 WorkingCopyOwner로 대체되었습니다. 작업 사본에 대한 개선된 지원을 사용하려면 작업 사본을 소유할 오브젝트가 있어야 합니다. IBufferFactory가 올바른 위치에 있어도, 이름은 새 작업 사본 메커니즘이 작동하는 방법을 적절하게 알리지 못합니다. WorkingCopyOwner를 한층 더 제안합니다. 또한 WorkingCopyOwner는 인터페이스보다는 추상 클래스로 선언되므로, 작업 사본 소유자의 개념을 차후에 더 발전시킬 수 있습니다. IBufferFactory에서 하나의 메소드가 영향을 받지 않는 WorkingCopyOwner로 이동합니다. WorkingCopyOwnerIBufferFactory가 이전 것임을 명백히 하기 위해 IBufferFactory를 구현하지 않습니다. IBufferFactory가 폐기되었습니다. API에서 IBufferFactory가 매개변수 또는 결과 유형으로 표시되는 다른 공간도 폐기되었습니다. 대체 API 메소드에서는 IBufferFactory 대신 WorkingCopyOwner를 언급합니다.

이 변경사항은 2진 호환성을 중단하지 않습니다.

이주할 때 유형 IWorkingCopy에 대한 모든 참조는 대신 ICompilationUnit를 참조합니다. IWorkingCopy의 단독 구현은 ICompilationUnit도 구현합니다. 이는 유형 IWorkingCopy의 오브젝트가 ICompilationUnit에 안전하게 캐스트할 수 있음을 의미합니다.

IBufferFactory를 구현하는 클래스는 WorkingCopyOwner 서브클래스에 의해 대체되어야 합니다. WorkingCopyOwnerIBufferFactory 자체를 구현하지 않아도, IBufferFactory를 구현하는 WorkingCopyOwner의 서브클래스를 선언할 수 있습니다. 이에 따라 이전 및 새 클래스 사이에 브릿지가 작성됩니다(IBufferFactorycreateBuffer(IOpenable)를 선언하는 반면 WorkingCopyOwnercreateBuffer(ICompilationUnit)를 선언합니다. ICompilationUnitIOpenable을 확장합니다).

IWorkingCopyIBufferFactory를 포함하는 변경사항이 서로 얽혀있으므로 둘 다 동시에 처리할 것을 권장합니다. 폐기에 대한 세부사항은 다음과 같습니다.

org.eclipse.help 플러그인의 구조 변경

도움말 시스템에 제공하고 도움말 시스템을 확장할 뿐만 아니라 도움말을 표시하기 위해 API 및 확장점을 보유하는 데 사용하는 org.eclipse.help 플러그인은 이제 도움말 자원에 제공하고 도움말 자원에 액세스하기 위한 API 및 확장점을 포함합니다. 이 플러그인에 포함된 기본 도움말 UI 구현의 일부가 구현 확장을 위한 API와 함께 새 플러그인 org.eclipse.help.base로 이동되었습니다. 도움말 UI를 제공하고 도움말을 표시하기 위한 API 및 확장점이 org.eclipse.ui 플러그인으로 이동되었습니다. 이 구조 변경으로 응용프로그램은 도움말 시스템에 대해 더 많은 융통성을 가질 수 있습니다. 새 구조를 사용하여 응용프로그램은 일반 Workbench를 기초로 자신의 고유 도움말 UI 및/또는 도움말 구현을 제공하거나 도움말 시스템을 전체적으로 생략할 수 있습니다.

영향받은 확장점 및 API 패키지는 도움말 시스템 자체에만 사용됩니다. 기존 플러그인과는 달리 이 변경의 영향을 받습니다. 완전성을 위해 여기에만 포함됩니다.

새로운 검색 UI API

사용자 정의 검색을 구현하기 위한 새 API가 3.0에 추가되었습니다. 원래 API는 3.0에서 폐기되었으므로 클라이언트가 패키지 org.eclipse.search.ui 및 org.eclipse.search.ui.text에서 새 API로 이식합니다.

클라이언트는 ISearchQuery, ISearchResultISearchResultPage 구현을 작성해야 합니다. 그런 다음 ISearchResultPage 구현을 새 org.eclipse.search.searchResultViewPages 확장점으로 제공해야 합니다.

ISearchResultISearchResultPage에 대한 기본 구현이 org.eclipse.search.ui.text 패키지에 제공됩니다.

MessageBox 및 DirectoryDialog의 널(null) 메시지(패키지 org.eclipse.swt.widgets)

3.0 이전에는, 문자열에 대해 값이 널인 SWT의 DirectoryDialog.setMessage(String string) 또는 MessageBox.setMessage(String string)를 호출할 경우 제목에 텍스트가 없는 대화 상자가 작성됩니다. 이 동작은 지정되지 않은 것이므로(널(null)을 전달하는 것은 허용되지 않음) 널을 리턴하는 것이 허용되지 않는 getMessage에 대해 문제점을 작성합니다. 3.0에서는 이제 널(null)을 전달하면 IllegalArgumentException 예외가 발생하고, 스펙은 수퍼클래스 Dialog.setMessage에서 메소드가 있는 행으로 가져와서 이를 언급하도록 변경했습니다. Dialog.setMessage를 사용할 경우, 전달된 문자열이 널(null)이 아니도록 확인하십시오. 제목에 텍스트가 없는 대화 상자를 원할 경우 간단히 빈 문자열을 전달하면 됩니다.

모달 진행상태 피드백 개선

동시 조작을 지원하려면 모달 진행상태를 표시하기 위한 더 정교한 방식이 필요합니다. 응답 결과의 일부로, IProgressService 클래스에서 추가 진행상태 지원이 구현되었습니다. ProgressMonitorDialog로 진행상태를 표시하는 기존 방식은 계속 작동합니다. 하지만 사용자 경험을 개선하려면 새 IProgressService로 이주할 것을 권장합니다.

문서 Eclipse 3.0에서 모달 진행상태 표시는 새 IProgressService로 이주하는 방법을 설명합니다.

디버그 조치 그룹 제거

디버그 조치 그룹 확장점(org.eclipse.debug.ui.debugActionGroups)이 제거되었습니다. Eclipse 3.0에서는 org.eclipse.platform.ui.activities 확장점을 통해 활동에 대한 지원이 Workbench에 추가되었습니다. 이 지원은 디버그 조치 그룹이 제공했던 모든 것을 제공하면서 사용하기는 더 쉬우며(모든 조치를 철저하게 지정하는 대신 패턴을 지원함) 이를 지원하기 위해 프로그램 방식의 API를 가지고 있습니다. 이전 확장점에 대한 참조를 제거하지 못해도 장애가 발생하지 않습니다. 확장점에 대한 참조는 단순히 무시됩니다. 제품 벤더는 Workbench 활동 지원을 사용하여 언어 특정 디버거 조치를 언어 특정 활동(예: C++ 디버깅 조치가 "Developing C++"라고 하는 활동과 연관될 수 있음)과 연관시키도록 권합니다.

BreakpointManager가 사용 불가능하게 될 수 있음

IBreakpointManager는 이제 메소드 setEnabled(boolean) 및 isEnabled()를 정의합니다. 중단점 관리자가 사용 불가능할 경우, 디버거는 등록된 모든 중단점을 무시해야 합니다. 디버그 플랫폼은 또한 클라이언트가 사용 가능 여부가 변경될 때 중단점 관리자에게 알리기 위해 등록할 수 있는 새 리스너 메커니즘 IBreakpointManagerListener를 제공합니다. 중단점 보기는 사용자에 대해 "모든 중단점 건너뛰기"를 허용하는 새 토글 조치로부터 이 API를 호출합니다. 중단점 관리자의 사용 가능을 받아들이지 않는 디버거는 사용자가 이 기능을 사용하려고 할 경우 다소 중단된 것으로 표시합니다.

[JDT 전용] Java 검색 구성원(패키지 org.eclipse.jdt.core.search)

Java에 가까운 언어(예: JSP, SQLJ, JWS 등)는 Java 검색에 참여할 수 있어야 합니다. 특히, 이 언어의 구현자는 다음을 수행할 수 있어야 합니다.

이와 같은 구현자를 검색 구성원이라고 합니다. 이 구현자는 SearchParticipant 클래스를 확장합니다. 검색 구성원은 검색 조회로 전달됩니다(SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)를 참조하십시오).

일치 항목을 색인화하거나 찾을 경우, 검색 구성원은 getByteContents() 또는 getCharContents()를 대체하여 문서 컨텐츠를 검색할 수 있는 SearchDocument의 서브클래스를 정의해야 합니다. 이 서브클래스의 인스턴스는 getDocument(String)로 리턴됩니다.

어떤 문서를 색인화하려는 검색 구성원은 SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath)를 사용하여 주어진 색인에서 주어진 문서의 색인화 스케줄을 지정합니다. 문서의 색인화 준비가 완료되면 기본적인 프레임워크가 SearchParticipant.indexDocument(SearchDocument, IPath)를 호출합니다. 그러면 검색 구성원이 문서의 컨텐츠를 가져와서 구문 분석한 후 SearchDocument.addIndexEntry(char[], char[])를 사용하여 색인 항목을 추가합니다.

색인화가 수행되고 나면 색인을 조회하고 SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)를 사용하여 일치 항목을 찾을 수 있습니다. 먼저 SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope)를 사용하여 각 검색 구성원에게 이 조회에 필요한 색인에 대해 요청합니다. 주어진 패턴과 일치하는 색인 항목마다 검색 구성원에게 요청하여 검색 문서가 작성됩니다(getDocument(String) 참조). 이 문서는 모두 locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor)를 사용하여 일치 항목을 찾을 수 있도록 검색 구성원에게 전달됩니다. 검색 구성원은 acceptSearchMatch(SearchMatch)를 사용하고 SearchMatch 서브클래스의 인스턴스를 전달하여 검색 일치 항목을 SearchRequestor에 알립니다.

검색 구성원은 작업의 일부를 기본 Java 검색 구성원에게 위임할 수 있습니다. 이 기본 구성원의 인스턴스는 SearchEngine.getDefaultSearchParticipant()를 사용하여 확보합니다. 예를 들어, 일치 항목을 찾을 것을 요청한 경우 SQLJ 구성원은 해당되는 .sql 문서에서 .java 문서를 작성하고 이 문서를 .java 문서로 전달하여 기본 구성원에게 작업을 위임합니다.