Eclipse 2.1과 3.0 사이의 비호환성

플러그인에 영향을 주는 Eclipse 2.1 및 3.0 간의 비호환성 방식으로 Eclipse가 변경되었습니다. 다음 항목에서는 변경된 영역에 대해 설명하고 2.1 플러그인을 3.0으로 이주하는 방법에 대한 지시사항을 제공합니다. 3.0에서 2.1 플러그인을 실행하는 중 문제가 발생하는 경우 다음 사항을 살펴 보면 됩니다.

  1. 플러그인 Manifest 버전
  2. 플랫폼 UI 플러그인 구조 변경
  3. 플랫폼 코어 런타임 플러그인의 구조 변경
  4. Xerces 플러그인 제거
  5. Eclipse 3.0의 동시성 향상
  6. IFiles에서 편집기 열기
  7. 편집기 이동 마커
  8. 편집기 실행기
  9. 편집기 레지스트리
  10. Workbench 마커 도움말 레지스트리
  11. 문서 편집기 문서 제공자
  12. 문서 편집기
  13. 제목없는 어노테이션 지원
  14. 콘솔 보기
  15. Java 중단점 리스너
  16. UI 스레드에서의 클립보드 액세스
  17. 키 다운 이벤트
  18. 사용자 정의 제어의 탭 순회
  19. SWT 테이블 및 트리 위지트(widget)에서의 선택 이벤트 순서
  20. 상태 오브젝트의 새 심각도 레벨
  21. 빌드 관련 자원 변경 알림
  22. 작업공간 오퍼레이션 중에 중간 알림
  23. URL 스트림 핸들러 확장
  24. 클래스 로드 순서
  25. 클래스 로더 보호 도메인이 설정되지 않음
  26. PluginModel 오브젝트 캐스팅
  27. 불완전한 ILibrary 구현
  28. URL 양식에 관한 올바르지 않은 가정
  29. BootLoader 메소드 이동/삭제
  30. 플러그인 내보내기에 플러그인의 JAR이 자동으로 포함되지 않음
  31. 런타임 API 다시 내보내기
  32. 플랫폼의 플러그인 구문 분석 메소드
  33. 단편으로 제공되는 플러그인 라이브러리
  34. 빌드 스크립트 변경사항
  35. PDE 빌드 Ant 타스크 변경사항
  36. eclipse.build Ant 타스크 변경사항
  37. eclipse.fetch Ant 타스크 변경사항
  38. install.ini 바꾸기

1. 플러그인 Manifest 버전

플러그인(및 플러그인 단편)의 Manifest 파일 헤더가 적절한 플러그인 Manifest 버전을 식별하는 새 행을 포함하도록 변경되었습니다. 3.0 이전에는 플러그인이 이 <?eclipse ...?> 행 중 하나를 전달하지 않았지만 3.0 이후에는 항상 이 행을 가지고 있어야 합니다. 이 변경은 Eclipse 런타임이 3.0으로 이식되지 못한 3.0 이전 플러그인을 확실하게 인식하여 자동으로 그 플러그인에 대해 더 나은 2진 호환성을 제공할 수 있도록 하기 위해서입니다. 이는 plugin.xml 파일의 일반적인 양식입니다(fragment.xml이 유사합니다).

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
    ...
</plugin>

PDE 3.0이 작성한 플러그인 Manifest는 자동으로 이 양식이 수반됩니다. PDE 플러그인 이주 도구를 사용하도록 하십시오. 이 도구는 표시된 행을 자동으로 2.1 플러그인의 Manifest와 플러그인 단편에 삽입하고 여기에 설명된 다른 많은 변경사항을 제시합니다.

이 지시문을 plugin.xml에 추가한 경우(수동으로 또는 PDE를 사용하여), 파일도 의존하는 플러그인을 명시적으로 나열하도록 갱신해야 합니다. 예를 들어, Eclipse 3.0 이전에는 org.eclipse.core.runtime 및 org.eclipse.core.boot에 대한 종속성이 묵시적이었습니다. 3.0에서는 org.eclipse.core.boot가 더 이상 필요하지 않으므로 개발자는 org.eclipse.core.runtime 또는 org.eclipse.core.runtime.compatibility를 적절하게 선택해야 합니다(아니면 둘 다 선택하지 말아야 합니다).

참고: 이는 2.1 2진 플러그인이 Eclipse 3.0에서 실행되는 방식에 영향을 주지 않는 비호환성 중 하나입니다.

2. 플랫폼 UI 플러그인 구조 변경

기본 플랫폼 UI 플러그인이었던 org.eclipse.ui 플러그인은 이제 일반(즉, IDE에 특정하지 않은) Workbench에 대해 API 및 확장점만 제공합니다. 선택적 및 IDE 특정 API와 확장점은 다른 플러그인으로 이동되었습니다.

이 변경의 영향은 다음 두 가지 사항입니다. (1) 이동된 org.eclipse.ui 확장점이 새 확장점 ID를 갖습니다. (2) 필수 플러그인 목록이 변경되었습니다.

다음 테이블에서 org.eclipse.ui 확장점은 다른 플러그인으로 이동되었으므로 확장점 ID가 변경됩니다. 기존 플러그인이 이동된 확장점에 확장을 제공할 경우, 플러그인 Manifest 파일에서 <extension> 요소의 "point" 속성에 있는 참조를 해당되는 새 확장점 ID를 참조하도록 변경해야 합니다. PDE 플러그인 이주 도구가 이 수정을 수행합니다.

참고: 이는 2.1 2진 플러그인이 Eclipse 3.0에서 실행되는 방식에 영향을 주지 않는 비호환성 중 하나입니다. Eclipse 3.0 런타임은 자동으로 3.0 이전 플러그인을 발견하여(앞에 언급한 <?eclipse version="3.0"?> 행이 플러그인 Manifest에 없을 경우) 자동으로 확장점 및 플러그인 종속성 변경사항에 적용합니다.

이전 확장점 ID

새 확장점 ID

org.eclipse.ui.markerHelp org.eclipse.ui.ide.markerHelp
org.eclipse.ui.markerImageProviders org.eclipse.ui.ide.markerImageProviders
org.eclipse.ui.markerResolution org.eclipse.ui.ide.markerResolution
org.eclipse.ui.projectNatureImages org.eclipse.ui.ide.projectNatureImages
org.eclipse.ui.resourceFilters org.eclipse.ui.ide.resourceFilters
org.eclipse.ui.markerUpdaters org.eclipse.ui.editors.markerUpdaters
org.eclipse.ui.documentProviders org.eclipse.ui.editors.documentProviders
org.eclipse.ui.workbench.texteditor.
markerAnnotationSpecification
org.eclipse.ui.editors.markerAnnotationSpecification

다음 테이블은 다른 플러그인으로 이동된, 이전에 org.eclipse.ui 플러그인이 제공한 API 패키지를 나열합니다. (API 패키지, 클래스, 필드 및 메소드의 이름은 변경되지 않았습니다.) 일부 경우, API 패키지는 이제 여러 플러그인 사이에 분할됩니다. 주어진 플러그인에 표시 가능한 API 클래스는 플러그인의 필수 플러그인 목록에 의해 판별되므로, 이 변경사항에서는 API 클래스에 대한 액세스를 다시 얻기 위해 기존 플러그인의 Manifest에 있는 "<requires>" 요소를 조정해야 할 수도 있습니다.

이 변경은 org.eclipse.ui 플러그인에 의존하는 플러그인에만 영향을 줍니다(즉, 플러그인 Manifest의 <requires> 섹션에 <import plugin="org.eclipse.ui"/>를 포함합니다). 다른 모든 플러그인은 영향을 받지 않습니다. 영향을 받을 경우, <import> 요소를 변경해야 할 수도 있습니다. 그렇지 않으면 플러그인이 필요로 하는 모든 API 클래스가 범위 안에 있도록 <import> 요소를 더 추가하십시오. 플러그인은 실제로 사용하는 플러그인에 관한 종속성만 언급하도록 하십시오. 불필요한 종속성을 포함하면 Java 클래스 로더가 모든 종속성에서 클래스를 검색해야 하므로 런타임 성능이 나빠질 수 있습니다. (PDE 플러그인 이주 도구는 종속성을 수정하므로 최소 세트를 판별하는 데 도움이 됩니다.)

API 패키지

2.1 플러그인

해당되는 3.0 플러그인

org.eclipse.jface.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.ui org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.actions org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.dialogs org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.editors.* org.eclipse.ui org.eclipse.ui.editor
org.eclipse.ui.model org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.part org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.texteditor org.eclipse.ui org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors
org.eclipse.ui.texteditor.* org.eclipse.ui org.eclipse.ui.workbench.texteditor
org.eclipse.ui.views.bookmarkexplorer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.contentoutline org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.markers org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.navigator org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.properties org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.tasklist org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.datatransfer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.newresource org.eclipse.ui org.eclipse.ui.ide

3. 플랫폼 코어 런타임 플러그인의 구조 변경

Eclipse 3.0 Platform Runtime은 OSGi를 기초로 하므로, 두 개의 플랫폼 런타임 플러그인 org.eclipse.core.runtime 및 org.eclipse.core.boot의 구조를 변경해야 합니다.

새 org.eclipse.core.runtime.compatibility 플러그인은 이전 API와 새 API 사이의 구현 브릿지를 제공하므로, 이전에 org.eclipse.core.runtime 및 org.eclipse.core.boot에서 발견되었던 많은 폐기된 API의 새로운 홈입니다. 플랫폼 런타임 확장점은 구조 변경 영향을 받지 않습니다.

기존 플러그인을 3.0으로 이주할 경우, 플러그인의 Manifest는 Eclipse 플랫폼 런타임 플러그인의 새 구조를 반영하기 위해 갱신되어야 합니다. PDE 플러그인 Manifest 이주 도구는 필요에 따라 종속성을 org.eclipse.core.runtime.compatibility에 추가합니다.

또한 플러그인을 3.0으로 표시하고(<?eclipse version="3.0"?>을 사용하여) 사용자 플러그인이 플러그인 클래스를 정의할 경우, 명시적으로 플러그인 Manifest에서 <import plugin="org.eclipse.core.runtime.compatibility"/>를 정의하거나 플러그인 클래스가 기본 생성자를 정의하는지 확인해야 합니다.

참고: 이는 2.1 2진 플러그인이 Eclipse 3.0에서 실행되는 방식에 영향을 주지 않는 비호환성 중 하나입니다. Eclipse 3.0 런타임은 자동으로 3.0 이전 플러그인을 발견하여( <?eclipse version="3.0"?> 행이 플러그인 Manifest에 없을 경우) 자동으로 플랫폼 런타임 변경사항에 보상합니다.

4. Xerces 플러그인 제거

org.eclipse.xerces 플러그인은 더 이상 필요하지 않으므로 삭제되었습니다. XML 구문 분석 지원이 J2SE 1.4에 내장되어 있으므로, Xerces 플러그인이 있으면 클래스 로더 충돌이 발생합니다. 이전에 org.eclipse.xerces 플러그인이 제공했던 javax.xml.parsers, org.w3c.dom.* 및 org.xml.sax.* API 패키지는 이제 J2SE 라이브러리에서 사용 가능합니다.

플러그인에 org.eclipse.xerces 플러그인이 필요할 경우, 언급된 종속성이 제거되도록 사용자의 플러그인 Manifest를 변경해야 합니다. 수행되고 나면 플러그인 코드는 추가 변경 없이 컴파일 및 실행해야 합니다.

org.eclipse.xerces 플러그인에 언급된 종속성을 가지고 있는 2.1 2진 플러그인에서는 표준 Eclipse 3.0 구성에서 실행할 때 전제조건이 없어집니다. 플러그인은 결국 활성화되지 않습니다.

5. Eclipse 3.0의 동시성 향상

Eclipse 3.0 이전에는 Eclipse가 거의 단일 스레드에서 작동했습니다. 대부분의 API 메소드 및 확장점은 UI 스레드를 블록화한 진행 대화 상자에서 생성된 스레드나 UI 스레드에서 작동했습니다. 대부분의 플러그인 작성자는 모든 UI 활동이 UI 스레드에서 발생했음을 확인하는 것과는 별도로, 스레드 안전성에 대해 많은 걱정을 할 필요가 없었습니다. Eclipse 3.0에서는 일반적으로 동시성이 더 향상되었습니다. 많은 조작이 배경 스레드에서 발생하며, 이 조작은 UI 스레드를 포함하여 다른 스레드와 동시에 실행될 수 있습니다. 코드가 배경 스레드에서 실행되는 모든 플러그인은 이제 해당 코드의 스레드 안전성에 대해 유의해야 합니다.

org.eclipse.core.runtime.jobs API를 사용하는 배경에서 명시적으로 조작을 실행하는 플러그인 외에도, 배경 스레드를 사용할 수 있도록 만드는 몇 가지의 플랫폼 API 기능 및 확장점이 있습니다. 이 기능에 연결되는 플러그인은 코드가 스레드 안전 상태인지 확인해야 합니다. 다음 테이블은 Eclipse 3.0에서 배경 스레드에서 모든 또는 일부 코드를 실행하는 확장점과 API를 요약한 것입니다.

확장점 또는 API 클래스

참고

org.eclipse.core.runtime.IRegistryChangeListener 배경에서 실행되는 Eclipse 3.0의 새 기능
org.eclipse.core.resources.IResourceChangeListener 이제는 배경에서 실행되는 AUTO_BUILD 이벤트
org.eclipse.core.resources.builders(확장점) 이제는 배경에서 실행되는 자동 빌드
org.eclipse.core.resources.ISaveParticipant 이제는 배경에서 실행되는 SNAPSHOT 이벤트
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider(확장점) 배경에서 실행되는 Eclipse 3.0의 새 기능
org.eclipse.ui.decorators(확장점) Eclipse 2.1에서 이미 배경에서 실행됨
org.eclipse.ui.startup(확장점) Eclipse 2.1에서 이미 배경에서 실행됨
org.eclipse.team.core.org.eclipse.team.core.repository(확장점) 이제는 많은 조작이 배경에서 실행됨
org.eclipse.team.ui.synchronizeParticipants(확장점) 배경에서 실행되는 Eclipse 3.0의 새 기능
org.eclipse.debug.core.launchConfigurationTypes(확장점) 이제는 배경에서 실행
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD는 이제 배경에서 실행되고, POST_RECONCILE는 이미 배경에서 실행되었음

코드를 스레드 안전 상태로 만들기 위해 사용 가능한 다양한 전략이 있습니다. 기본 솔루션은 모든 작업이 UI 스레드에서 발생하도록 하여 직렬화된 실행이 되도록 하는 것입니다. 이는 CPU 집약적 처리를 수행하지 않는 UI 플러그인에 대한 일반적인 접근 방식입니다. 이를 수행할 경우, Display.syncExec의 고유한 교착 상태 위험성에 유의하십시오. 일반적으로 Display.asyncExec가 더 안전합니다. 코드 실행 시기에 대한 정확한 제어가 없는 대신 교착 상태 위험성이 도입되지 않기 때문입니다.

코드를 스레드 안전 상태로 만들기 위한 다른 기술은 다음과 같습니다.

6. IFiles에서 편집기 열기

다음 메소드가 org.eclipse.ui.IWorkbenchPage 인터페이스에서 삭제되었습니다. IWorkbenchPage는 일반 Workbench에서 선언되지만 메소드는 본래 자원에 고유합니다.

이 IWorkbenchPage.openEditor 메소드의 클라이언트는 클래스 org.eclipse.ui.ide.IDE(org.eclipse.ui.ide 플러그인에 있는)에 선언된 해당되는 공용 정적 메소드를 대신 호출해야 합니다.

이 IWorkbenchPage.openSystemEditor(IFile) 메소드의 클라이언트는 새 FileEditorInput(IFile)을 사용하여 IFile을 IEditorInput으로 변환한 후 openEditor(IEditorInput,String) 메소드를 호출해야 합니다. 즉, page.openSystemEditor(file)을 page.openEditor(새 FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID)로 재작성하십시오. 참고: 편집기 ID IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID를 사용하는 클라이언트는 org.eclipse.ui.IPathEditorInput(FileEditorInput이 수행하는)을 구현하는 편집기 입력을 전달해야 합니다.

참고: 이는 2.1 2진 플러그인이 Eclipse 3.0에서 실행되는 방식에 영향을 주지 않는 비호환성 중 하나입니다. Eclipse 3.0에는 삭제된 openEditor 및 openSystemEditor 메소드 중 하나를 사용하여 기존 2.1 플러그인 2진이 이 API 변경에도 불구하고 2.1에서와 같이 계속 작동하도록 하는 2진 런타임 호환성 메커니즘이 포함되어 있습니다. (삭제된 메소드는 org.eclipse.ui.workbench.compatibility 단편에 의해 효율적으로 "다시 추가"됩니다.)

7. 편집기 이동 마커

다음 메소드가 org.eclipse.ui.IEditorPart 인터페이스에서 삭제되었습니다. IEditorPart는 일반 Workbench에서 선언되지만 메소드는 본래 자원에 고유합니다.

해당되는 메소드는 org.eclipse.ui.part 패키지에서 IEditorPart(즉, EditorPart, MultiEditor, MultiPageEditorPart 및 MultiPageEditor)를 구현하는 클래스에서도 삭제되었습니다.  

이 메소드를 호출하는 클라이언트는 편집기 파트가 org.eclipse.ui.ide.IGotoMarker를 구현하거나 이에 맞게 변경할 경우(org.eclipse.ui.ide 플러그인에서) 대신 테스트해야 합니다. 이 경우 gotoMarker(IMarker)를 호출하십시오. IDE 클래스는 이를 수행하기 위한 편리한 메소드(IDE.gotoMarker(편집기, 마커))를 가지고 있습니다.

IMarker 정보를 기초로 자체의 위치를 지정할 수 있는 편집기를 구현하는 클라이언트는 org.eclipse.ui.ide.IGotoMarker를 구현하거나 이에 맞게 변경해야 합니다.

IGotoMarker의 유일한 메소드는 gotoMarker(IMarker)이고 이전 IEditorPart.gotoMarker(IMarker)와 같은 서명 및 스펙을 가지고 있으므로, 기존 편집기 구현은 클래스 정의의 구현 절에 IGotoMarker를 포함시켜서 이 변경에 맞게 수정해야 합니다.

이 메소드를 호출하는 코드가 있는 2.1 2진 플러그인은 표준 Eclipse 3.0 구성에서 실행될 경우 클래스 링크 오류 예외가 발생합니다.

8. 편집기 실행기

편집기 실행기 인터페이스 org.eclipse.ui.IEditorLauncher는 외부 편집기를 제공하는 플러그인에 의해 구현됩니다. 다음 메소드가 이 인터페이스에서 제거되었습니다. IEditorLauncher는 일반 Workbench에서 선언되지만 메소드는 본래 자원에 고유합니다.

다음과 같이 대체되었습니다.

IEditorLauncher.open(file)을 호출하는 클라이언트는 대신 IEditorLauncher.open(file.getLocation())을 호출해야 합니다. 이 인터페이스를 구현하는 클라이언트는 open(IFile) 구현을 open(IPath) 구현으로 바꿔야(또는 증가시켜야) 합니다.

이 메소드를 호출하는 코드가 있는 2.1 2진 플러그인은 표준 Eclipse 3.0 구성에서 실행될 경우 클래스 링크 오류 예외가 발생합니다.

9. 편집기 레지스트리

다음 메소드가 org.eclipse.ui.IEditorRegistry 인터페이스에서 제거되었습니다. IEditorRegistry는 일반 Workbench에서 선언되지만 메소드는 본래 자원에 고유합니다.

getEditors(file) 또는 getImageDescriptor(file)를 호출하는 클라이언트는 "String"에 해당되는 메소드를 호출해야 합니다. setDefaultEditor(IFile file, String editorId) 및 getDefaultEditor(IFile file)를 호출하는 클라이언트는 클래스 org.eclipse.ui.ide.IDE(org.eclipse.ui.ide 플러그인에 있는)에 선언된 해당되는 공용 정적 메소드를 대신 호출해야 합니다. 또한, 메소드 IEditorRegistrygetDefaultEditor()에 대한 API 계약이 변경되었습니다. 이 메소드 역시 이제는 폐기되어 항상 '시스템 외부 편집기' 편집기 설명자를 리턴합니다. 이 변경은 리턴된 기본 편집기가 문서 편집기일 것으로 간주한 클라이언트에 영향을 줍니다.

시스템 외부 편집기 및 시스템 In-Place 편집기 ID(SYSTEM_EXTERNAL_EDITOR_ID 및 SYSTEM_INPLACE_EDITOR_ID)를 표시하는 새 상수가 있습니다. 이 두 가지의 편집기를 사용하려면 org.eclipse.ui.IPathEditorInput을 구현하거나 이에 맞게 변경하는 편집기 입력이 필요합니다. In-Place 편집기 설명자는 In-Place 편집을 지원하지 않는 Eclipse 구성에 존재하지 않습니다.

10. Workbench 마커 도움말 레지스트리

다음 메소드가 org.eclipse.ui.IWorkbench 인터페이스에서 삭제되었습니다. IWorkbench는 일반 Workbench에서 선언되지만 메소드는 본래 자원에 고유합니다.

IWorkbench.getMarkerHelpRegistry()의 클라이언트는 대신 공용 정적 메소드 org.eclipse.ui.ide.IDE.getMarkerHelpRegistry()(org.eclipse.ui.ide 플러그인에 있는)를 호출해야 합니다.

이 메소드를 호출하는 코드가 있는 2.1 2진 플러그인은 표준 Eclipse 3.0 구성에서 실행될 경우 예외가 발생합니다.

11. 문서 편집기 문서 제공자

org.eclipse.ui.texteditor.AbstractTextEditor가 IFile과 관계가 없도록 만들기 위해, org.eclipse.ui.texteditor.AbstractDocumentProvider는 문서 제공자 조작(DocumentProviderOperation) 및 문서 제공자 조작 실행 프로그램(IRunnableContext) 개념을 도입했습니다. 재설정, 저장 또는 동기화를 수행하도록 요청한 경우, AbstractDocumentProvider는 문서 제공자 조작을 작성하고 조작 실행 프로그램을 사용하여 조작을 실행합니다. 실행 가능 컨텍스트는 getOperationRunner 메소드를 통해 서브클래스가 제공할 수 있습니다. 다음은 클라이언트가 알맞게 변경해야 하는 변경사항의 요약입니다.

AbstractDocumentProvider 서브클래스 org.eclipse.ui.editors.text.StorageDocumentProvider는 항상 널(null)을 리턴하도록 getOperationRunner 메소드를 구현합니다. 이는 StorageDocumentProvider의 서브클래스가 이 변경의 영향을 받지 않아야 함을 의미합니다.

StorageDocumentProvider 서브클래스 org.eclipse.ui.editors.text.FileDocumentProvider는 WorkspaceModifyOperation에 지정된 DocumentProviderOperations의 실행을 위해 IRunnableContext를 리턴하는 getOperationRunner 메소드를 구현합니다. 다른 FileDocumentProvider 변경사항은 다음과 같습니다.

12. 문서 편집기

org.eclipse.ui.texteditor.AbstractTextEditor 변경사항은 다음과 같습니다.

AbstractTextEditor 서브클래스 org.eclipse.ui.texteditor.StatusTextEditor는 술부 메소드 isErrorStatus(IStatus)를 제공합니다. 주어진 상태를 오류로 간주해야 하는지 여부를 결정하기 위해 서브클래스를 대체할 수 있습니다.

org.eclipse.ui.editors.text.AbstractDecoratedTextEditor 변경사항은 다음과 같습니다.

13. 제목없는 어노테이션 지원

제목없는 어노테이션 지원 도입의 일부로, 다음과 같이 어노테이션이 변경되었습니다.

        org.eclipse.jface.text.source.Annotation 
        org.eclipse.jface.text.source.AnnotationModel 
        org.eclipse.jface.text.source.AnnotationModelEvent 
        org.eclipse.jface.text.source.IAnnotationModel 
        org.eclipse.jface.text.source.IAnnotationModelListener 
        org.eclipse.jface.text.source.IAnnotationModelListenerExtension

14. 콘솔 보기

Eclipse 3.0에는 새 일반 콘솔 지원이 있습니다. 일반 콘솔은 창 > 보기 표시 > 기본 > 콘솔을 통해 사용 가능하며 Eclipse 디버그와 Ant 통합에 의해 사용됩니다.

콘솔에 대한 보기 ID는 org.eclipse.debug.ui.ConsoleView에서 org.eclipse.ui.console.ConsoleView로 변경되었습니다. 프로그램 방식으로 콘솔을 여는 2.1 플러그인은 이전 보기가 더 이상 존재하지 않으므로 실패합니다.

15. Java 중단점 리스너

3.0에서, 리스너가 "don't care"를 제안할 수 있도록 메소드 org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) 및 installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType)이 부울에서 int로 변경되었습니다. 3.0 이전 릴리스에서는 리스너가 중단점을 히트했을 때 "suspend" 또는 "don't suspend"만 제안하고 중단점이 설치되려고 할 때 "install" 또는 "don't install"만 제안되었습니다. 3.0에서는 리스너가 위의 두 알림 중 하나에 대해 "don't care"도 제안할 수 있습니다. 이로서 클라이언트는 걱정이 되는 상황에서 결정적인 제안만 작성할 수 있습니다. "중단점 히트" 알림의 경우에는 중단점이 임의 리스너가 "suspend"를 제안하거나 모든 리스너가 "don't care"를 제안할 경우 일시중단하게 됩니다. 그리고 최소 하나의 리스너가 "don't suspend"를 제안하고 어떤 리스너도 "suspend"를 제안하지 않을 경우에는 일시중단하지 않습니다. 마찬가지로, "breakpoint installing" 알림의 경우, 중단점은 리스너가 설치할 것을 제안할 경우, 또는 모든 리스너가 "don't care"를 제안할 경우에 설치됩니다. 최소 하나의 리스너가 "don't install"을 제안하고 어떤 리스너도 "install"을 제안하지 않을 경우 중단점은 설치되지 않습니다. 일반적으로, 구현자는 어느 쪽이든지 강력한 견해를 가지고 있지 않으면 DONT_CARE를 리턴해야 합니다. 예를 들어, "suspend"를 제안하면 다른 리스너 제안 "don't suspend"를 대체한다는 점을 기억해야 합니다.

IJavaBreakpointListener 인터페이스는 Java 코드로 중단점을 작성하거나 중단점에 반응하는 클라이언트가 구현합니다. JDT 자체를 넘어서는 소수의 클라이언트가 있습니다. 이 변경으로 수정되는 문제점(버그 37760)을 보고한 클라이언트를 저장하십시오. 이는 IJavaBreakpointListener 인터페이스를 구현하는 기존 코드에 대한 중단 변경입니다. 이 코드는 3.0에서 컴파일 또는 실행되기 전에 적절한 int 값을 리턴하도록 수정해야 합니다.

16. UI 스레드에서의 클립보드 액세스

3.0 이전에는, SWT 클래스 org.eclipse.swt.dnd.Clipboard의 메소드가 UI 스레드가 아닌 다른 스레드에서 실행되도록 허용되었습니다. 이 실수로 운영 체제가 모든 클립보드 상호작용을 UI 스레드에서 수행하도록 요구하는 GTK에서 실패가 발생했습니다. 많은 응용프로그램이 단일 스레드 상태이고 Windows에서 대부분의 테스트를 받으므로 이전에서 실수가 드러나지 않았습니다. 클립보드 API가 플랫폼 사이에 지속 가능하도록 하기 위해, 3.0에서는 UI가 아닌 스레드에서 호출한 경우 SWT 예외(ERROR_THREAD_INVALID_ACCESS)가 발생하도록 모든 클립보드 API 메소드의 구현 및 스펙이 변경되었습니다. 클립보드 서비스는 보통 많은 클라이언트가 이 중단 변경에서 격리되도록 하는 Eclipse 컴포넌트(예: 문서 편집기)에 의해 자동으로 제공됩니다. 클립보드를 직접 사용하는 기존 코드는 UI 스레드로 액세스를 이동하는 것이 적절한 경우 Display.asyncExec 또는 syncExec를 사용하여 올바른 스레드에서 API 메소드가 호출되는지 확인해야 합니다.

17. 키 다운 이벤트

3.0에서, SWT는 작업이 OS에서 수행되기 전에 키 다운 이벤트를 보고합니다. 이는 3.0 이전 버전에서보다 훨씬 빠릅니다. 이 변경은 위지트(widget)가 문자를 처리할 수 있는 기회를 갖기 전에 키 이벤트를 인터셉트해야 하는 Eclipse에서의 키 바인딩을 지원하기 위해 수행되었습니다. 이 변경의 결과는 하위 레벨 org.eclipse.swt.SWT.KeyDown 이벤트를 직접 처리하는 코드에 표시 가능합니다. 예를 들어, 이는 텍스트 위지트의 리스너가 키 다운 이벤트를 수신할 때 위지트의 컨텐츠(getText())가 방금 입력한 키를 아직 포함하지 않음을 의미합니다(3.0 이전에는 포함했습니다). 현재 키를 포함하는 위지트에서 전체 텍스트를 가져오기 위한 권장되는 방법은 하위 레벨 SWT.KeyDown 이벤트가 아닌 더 높은 레벨의 SWT.Modify 또는 SWT.Verify 이벤트를 처리하는 것입니다. 이미 이 방식으로 수행하는 코드는 이 변경의 영향을 받지 않습니다.

18. 사용자 정의 제어의 탭 순회

3.0 이전에는, 초점이 SWT 클래스 org.eclipse.swt.widgets.Canvas나 해당되는 서브클래스(사용자 정의 위지트를 포함하여) 중 하나에 있을 경우 Ctrl+Tab, Shift+Tab, Ctrl+PgUp 또는 Ctrl+PgDn을 누르면 키 이벤트를 보고하지 않고 자동으로 다음/이전 위지트로의 순회가 트리거됩니다. 이 동작은 지정하지 않았지만, Canvase가 입력된 모든 키를 확인하는 규칙에 대해 카운터를 실행합니다. 순회를 처리하는 적절한 방법은 순회 리스너를 등록하는 것입니다. 3.0에서의 Eclipse 키 바인딩을 적절하게 지원하기 위해, 이제는 Canvas가 순회하는 대신 Ctrl+Tab, Shift+Tab, Ctrl+PgUp 및 Ctrl+PgDn 키 이벤트를 확인하도록 기본 동작이 변경되었습니다. 원래 Canvas를 사용하거나 Canvas의 서브클래스를 정의할 경우, 순회 리스너를 등록하는지 확인하십시오.

19. SWT 테이블 및 트리 위지트(widget)에서의 선택 이벤트 순서

SWT 클래스 org.eclipse.swt.widgets.Table 및 Tree에서 항목을 마우스로 선택하면 모든 운영 환경에서 일정하게 이벤트 시퀀스 MouseDown-Selection-MouseUp이 생성됩니다. 마찬가지로, 키보드 선택사항은 모든 운영 환경에서 일정하게 이벤트 시퀀스 KeyDown-Selection-KeyUp을 생성합니다. 3.0 이전에는 이벤트 순서가 일정하지 않았습니다. Motif 및 Photon에서 항상 Selection 이벤트를 먼저 보고하여 나머지와 일치하지 않습니다(즉, Selection-MouseDown-MouseUp 또는 Selection-KeyDown-KeyUp). 3.0의 경우, Motif 및 Photon의 이벤트 순서가 다른 것과 일치하도록 변경되었습니다. {Windows, GTK} 및 {Motif, Photon}에서 올바르게 작동했던 기존 코드는 영향을 받지 않습니다. 그러나 올바르지 않은 이벤트 순서에 의존하지 않도록 코드를 확인하는 것이 권장됩니다.

20. 상태 오브젝트의 새 심각도 레벨

org.eclipse.core.runtime.IStatus에는 취소를 표시하기 위해 사용할 수 있는 새로운 심각도 상수인 IStatus.CANCEL이 있습니다. IStatus.OK, INFO, WARNINGERROR로 제한되는 가능한 심각도 세트에 의존하는 IStatus.getSeverity() 호출자는 이 추가의 영향을 받습니다. getSeverity 호출자는 새 심각도를 포함하도록 코드를 갱신해야 합니다.

21. 빌드 관련 자원 변경 알림

Eclipse 3.0에서, 작업공간 자동 빌드는 이제 배경 스레드에서 발생합니다. 이는 org.eclipse.core.resources.IResourceChangeEvent로의 API 계약 변경을 요구했습니다. IResourceChangeEvent 계약은 이전에 모든 작업공간 변경사항에 대해 다음 순서의 이벤트를 보장했습니다.

  1. 적용 가능할 경우 PRE_DELETE 또는 PRE_CLOSE 이벤트 알림
  2. 조작 수행
  3. PRE_AUTO_BUILD 이벤트 알림
  4. 자동 빌드가 설정된 경우 점층적인 작업공간 빌드 수행
  5. POST_AUTO_BUILD 이벤트 알림
  6. POST_CHANGE 이벤트 알림

이제는 자동 빌드가 배경에서 실행되므로, 더 이상 AUTO_BUILD 이벤트와 POST_CHANGE 이벤트 사이의 임시 관계에 대한 보증이 없습니다. Eclipse 3.0에서는, 위의 구조에 있는 3 - 5 단계가 조작에서 제거됩니다. 결과 그림은 다음과 유사합니다.

  1. 적용 가능할 경우 PRE_DELETE 또는 PRE_CLOSE 이벤트 알림
  2. 조작 수행
  3. POST_CHANGE 이벤트 알림

정기적으로, 플랫폼은 배경 작업공간 빌드 조작을 수행합니다. 이는 자동 빌드의 설정 또는 해제 여부에 관계없이 발생합니다. 이 빌드가 발생하는 정확한 시간은 지정되지 않습니다. 빌드 조작 구조는 다음과 유사하게 됩니다.

  1. PRE_BUILD 이벤트 알림(PRE_BUILDPRE_AUTO_BUILD의 새 이름임)
  2. 자동 빌드가 설정된 경우 증분 작업공간 빌드 수행
  3. POST_BUILD 이벤트 알림(POST_BUILDPOST_AUTO_BUILD의 새 이름임)
  4. POST_CHANGE 이벤트 알림

자동 빌드 리스너가 수신한 델타에 대한 참조점은 변경 후 리스너와 다르게 됩니다. 빌드 리스너는 마지막 빌드 조작 끝 이후의 모든 변경사항 알림을 수신합니다. 변경 후 리스너는 마지막 변경 후 알림 이후의 모든 변경사항을 설명하는 델타를 수신합니다. 이 새 구조는 Eclipse 1.0 이후로 적용되었던 자원 변경 리스너의 세 가지 특성을 보유합니다.

그러나 이 접근 방식에는 중요한 차이점이 있습니다. Eclipse 3.0 이전에는, 자동 빌드 리스너가 항상 POST_CHANGE 리스너 이전에 호출되었습니다. 이러한 이유로, 자동 빌드 리스너가 수신한 델타는 항상 POST_CHANGE 리스너가 수신한 델타의 서브세트였습니다. 이 관계는 이제 본질적으로 반대로 되었습니다. 자동 빌드 리스너는 마지막 배경 빌드 끝 이후로 POST_CHANGE 리스너에 제공된 모든 델타의 상위 세트인 델타를 수신합니다. 이전과 같이, 자동 빌드 리스너는 작업 공간을 수정할 수 있지만 변경 후 리스너는 수정할 수 없습니다.

작업공간 변경 조작 완료 시 AUTO_BUILD 이벤트 리스너에게 알리는 것은 이제 더 이상 사실이 아닙니다. IWorkspace.addResourceChangeListener(IResourceChangeListener)로 자원 변경 리스너를 등록하는 클라이언트 코드는 AUTO_BUILD 이벤트가 이 리스너에 보고되지 않았으므로 이 변경의 영향을 받지 않습니다. 그러나 IWorkspace.addResourceChangeListener(IResourceChangeListener,int)를 사용하고 AUTO_BUILD 이벤트를 포함하는 이벤트 마스크를 지정하는 클라이언트는 자동 빌드 리스너가 실행되는 시기나 실행되는 스레드에 관한 사항을 가정할 경우 이 변경으로 중단될 수 있습니다. 예를 들어, 자동 빌드 리스너가 작업공간에 변경사항을 반영하기 위해 도메인 모델을 갱신하는 경우, 이 갱신은 작업공간 변경 조작이 리턴할 때 발생하지 않았을 수 있습니다. 이 방식에서는 UI 레벨 코드만 영향을 받을 수 있으므로 가치가 없습니다. API를 통해 호출되는 코어 레벨 코드는 IWorkspaceRunnable 범위 내에서 호출할 수 있으므로, 자원 변경 리스너를 호출할 시기에 대해 확신할 수 없습니다. 이 중단에 대해 제안되는 수정사항은 조작 완료 이전에 알림이 발생되어야 할 경우 빌드 리스너 대신 POST_CHANGE를 사용하는 것입니다.

22. 작업공간 오퍼레이션 동안 중간 알림

더 이상 IWorkspaceRunnable의 동적 범위에서 발생하는 모든 자원 변경사항이 단일 알림으로 일괄처리된다고 보증하지 못합니다. 이 메커니즘은 불필요한 빌드 및 알림을 피하기 위해 계속 일괄처리 변경사항에 사용할 수 있지만 플랫폼은 이제 조작 동안 알림을 수행할 것을 결정할 수 있습니다. 이 API 계약 범위는 기존 클라이언트에 대한 중단 변경이 되지 않습니다. 장기 실행 조작 동안 정기적으로 IWorkspace.checkpoint를 호출할 것을 결정하는 플랫폼과 같습니다. 이 변경의 이유는 이제 여러 스레드에 대해 동시에 작업공간을 수정할 수 있기 때문입니다. 하나의 스레드가 작업공간 수정을 완료할 경우 다른 조작이 아직 완료되지 않은 경우에도 응답성 문제점을 방지하기 위해 알려야 합니다. 이 변경으로 사용자는 조작을 완료하기 전에 자원 세트에 대한 작업을 시작할 수도 있습니다. 예를 들어, 사용자는 이제 계속 체크아웃 처리 중인 프로젝트에서 파일 찾아보기를 시작할 수 있습니다. 새 메소드 IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor)에는 선택적 플래그 AVOID_UPDATE가 있습니다. 이 플래그는 정기적 갱신을 원하는지 지정하기 위해 조작이 플랫폼에 대한 힌트로 사용할 수 있습니다.

23. URL 스트림 핸들러 확장

영향을 받는 대상: org.eclipse.core.runtime.urlHandlers 확장점에 확장을 제공하는 플러그인.

설명: org.eclipse.core.runtime.urlHandlers 확장점에 대한 계약이 OSGi가 제공하는 URL 스트림 핸들러 서비스를 사용하도록 변경되었습니다. OSGi 지원은 Eclipse 2.1에서의 지원보다 낫고 동적 핸들러를 올바르게 처리합니다. 기본 Java URL 핸들러 메커니즘에 대해 다양한 설계 문제가 있으므로, OSGi 핸들러 서비스에 대해 등록된 URLStreamHandlers는 org.osgi.service.url.URLStreamHandlerService를 구현해야 합니다.

필요한 조치: 이전에는 핸들러 클래스가 java.net.URLStreamHandler를 구현하고 urlHandlers 확장점을 확장해야 했습니다. 확장점은 더 이상 지원되지 않으며 핸들러는 org.osgi.service.url.URLStreamHandlerService 인터페이스를 구현하도록 갱신해야 합니다. OSGi 프레임워크는 이 역할을 채우기 위해 사소하게 서브클래스화할 수 있는 추상 기본 클래스(org.osgi.service.url.AbstractURLStreamHandlerService)를 제공합니다.

확장점을 사용하여 핸들러를 등록하는 대신 플러그인은 이제 서비스로 핸들러를 등록하여 이를 수행해야 합니다. 예를 들어,

    Hashtable properties = new Hashtable(1);
    properties.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] {MyHandler.PROTOCOL});
    String serviceClass = URLStreamHandlerService.class.getName();
    context.registerService(serviceClass, new MyHandler(), properties);

24. 클래스 로드 순서

영향을 받는 대상: 다른 플러그인에서도 제공될 경우 패키지를 제공하는 플러그인. 아주 제한된 몇 개의 플러그인이 이 변경의 영향을 받으며 영향을 받는 플러그인 중 일부는 실제로 이득을 얻습니다(아래 참조).

설명: Eclipse 2.x에서, 클래스 로더는 (1) 상위 클래스 로더(사례에서 Java 시동 클래스 로더), (2) 해당되는 고유 클래스 경로 컨텐츠, 마지막으로 (3) 선언된 순서에 있는 해당되는 모든 전제조건 순서로 클래스를 검색합니다. OSGi는 이 모델에 대한 최적을 제공합니다. 이 접근 방식에서 클래스 로더는 (1) 상위 클래스 로더(효율적으로는 Java 시동 클래스 로더), (2a) 조회하는 패키지에서 클래스를 제공하기 위한 알려진 단일 전제조건이나 (2b) 원하는 클래스에 대한 고유 클래스 경로 항목을 순서대로 찾습니다.

클래스 로더는 자체를 볼 것인지 가져온 패키지와 필수 패키지를 기초로 해당되는 전제조건을 찾을 것인지 판별합니다. 이 정보는 일반적인 플러그인의 케이스에 있는 플러그인 컨텐츠를 통해 추측하며 명시적 OSGi 번들 Manifest를 사용하여 플러그인의 케이스에 직접 지정합니다. 어느 케이스든지, 어느 클래스 로더가 어느 패키지에 대한 클래스를 제공할 것인지 추측하여 알려집니다. 이는 성능 개선과 동일 클래스를 제공하는 여러 전제조건들의 난처한 문제점에 대한 솔루션을 제공합니다.

예를 들어, 둘 다 org.xml 패키지의 다양한 클래스를 포함하는 Xerces 및 Xalan 케이스를 생각해 보십시오. 첫 번째 접근 방식을 사용할 경우 Xerces 플러그인은 해당 클래스의 사본을 찾는 반면 Xalan 플러그인은 해당되는 사본을 찾습니다. 이 플러그인은 통신해야 하므로 ClassCastExceptions가 발생합니다. 두 번째 접근 방식을 사용할 경우, 두 개의 플러그인 중 하나만 중복 클래스를 제공하고 두 플러그인 모두는 동일 사본을 찾습니다.

필요한 조치: 필요한 조치는 유스 케이스의 특수성에 달려 있습니다. 영향을 받는 개발자는 클래스 경로를 검토하고 발생할 수 있는 충돌을 해결해야 합니다.

25. 클래스 로더 보호 도메인이 설정되지 않음

영향을 받는 대상: 항상 클래스 로드의 보호 도메인이 설정될 것으로 예상하는 플러그인.

설명: Eclipse 2.1에서 플러그인 클래스 로더는 java.security.SecureClassloaders였으며 항상 보호 도메인이 설정되어 있었습니다. Eclipse 3.0에서는 클래스 로더가 SecureClassloader를 확장하지 않으므로 Java 보안이 설정된 경우(보통의 경우가 아님)에만 보호 도메인을 설정합니다.

필요한 조치: 필요한 조치는 플러그인이 보호 도메인을 사용하는 시나리오에 따라 다릅니다.

26. PluginModel 오브젝트 캐스팅

영향을 받는 대상: org.eclipse.core.runtime.IPlugin* 유형 오브젝트를 org.eclipse.core.runtime.model.Plugin*Model로 캐스팅하는 플러그인. 이 인터페이스와 모델 클래스 사이의 관계가 Eclipse 2.1 API에 지정되지 않아도, 2.1 구현에서 이 관계에 따라 플러그인 인스턴스를 발견했으므로 이 변경을 명시적으로 호출합니다.

설명: Eclipse API는 플러그인 및 플러그인 레지스트리에 관련되는 일련의 인터페이스(예: IPluginDescriptor)와 소위 "모델" 클래스(예: PluginDescriptorModel)를 제공합니다. Eclipse 2.1 구현에서는 모델 클래스가 관련 인터페이스를 구현합니다. 새로운 OSGi 기반 런타임에서, 플러그인 레지스트리는 플러그인의 클래스 로딩 및 전제조건 측면과 확장 및 확장점 측면 사이의 구분을 허용하기 위해 상당부분 개정되었습니다. 이와 같이 Eclipse 3.0 런타임은 2.1에 있는 구현 관계를 유지할 수 없습니다.

필요한 조치: 비API 관계에 의존하는 플러그인은 유스 케이스에 따라 코드를 개정해야 합니다. 이에 대한 자세한 정보는 이 문서의 권장 변경사항 섹션과 관련된 클래스 및 메소드의 Javadoc에 제공되어 있습니다.

27. 불완전한 ILibrary 구현

영향을 받는 대상: org.eclipse.core.runtime.ILibrary를 사용하는 플러그인.

설명: 새 런타임은 Eclipse와 다르고 호환 불가능한 양식으로 클래스 경로 항목을 유지보수합니다. 결과적으로, 호환성 계층은 ILibrary 오브젝트처럼 기본적인 OSGi 구조를 올바르게 모델링할 수 없습니다. 런타임의 호환성 지원은 ILibrary 오브젝트를 작성하지만 라이브러리의 경로를 제외하고 모든 것에 대해 기본값을 가정해야 합니다.

필요한 조치: ILibrary의 사용자는 적절한 번들(Bundle.getHeaders() 참조)에서 원하는 헤더 값(예: Bundle-Classpath)에 액세스하고 ManifestElement 헬퍼 클래스를 사용하여 항목을 해석할 것을 고려해야 합니다. 세부사항은 클래스 Javadoc를 참조하십시오.

28. URL 양식에 관한 올바르지 않은 가정

영향을 받는 대상: 설치 구조, 위치 및 로컬 파일 시스템 레이아웃에 관한 사항을 가정하는 플러그인.

설명: IPluginDescriptor.getInstallURL()과 같은 메소드는 특정 양식의 URL을 리턴합니다. 양식을 지정하지 않음에도 불구하고, 다양한 플러그인이 현재 구현을 기초로 가정합니다. 예를 들어, 플러그인은 file: URL을 가져오고 URL.getFile()을 사용하며 결과에 대해 java.io.File 조작을 사용할 것을 예상할 수 있습니다. 현재까지는 연구 가능한 방식이었지만 오히려 빈약한 접근 방식이었습니다. 예를 들어, 플러그인이 웹 서버에 설치된 경우 http: URL을 리턴할 수 있습니다. 새 Eclipse 3.0 런타임은 더 유연하면서 실행 구성에 대해 더 많은 가능성을 개방합니다(예를 들어, 디렉토리에서 탐색하기 보다는 JAR에서 전체 플러그인을 유지보수합니다). 즉, 새 OSGi 기반 런타임은 실제로 2.1 API를 중단하지 않는 반면 현재 플러그인에서의 가정사항이 올바르지 않는 더 많은 케이스를 노출합니다.

필요한 조치: 플러그인 작성자는 액세스해야 하는 정보가 getResource()를 통해 사용 가능하고 클래스 경로에 있는지 확인해야 합니다. 그렇지 않으면 관련 API를 사용하여 플러그인 컨텐츠에 액세스해야 합니다(예: Bundle.getEntry(String)).

29. BootLoader 메소드 이동/삭제

영향을 받는 대상: org.eclipse.core.boot.BootLoader 클래스에서 특정 메소드를 호출하는 비플러그인 코드.

설명: 정적 메소드인 BootLoader.startup(), shutdown() 및 run()은 OSGi 프레임워크의 일부인 org.eclipse.core.runtime.adaptor.EclipseStarter로 이동되었습니다. 이 API는 startup.jar의 main()과 OSGi 프레임워크/Eclipse 런타임 사이의 인터페이스입니다. 런타임 구조 변경에서는 이 메소드들을 BootLoader에서 유지하는 것이 허용되지 않았습니다. 이전 BootLoader 클래스는 이제 런타임 호환성 계층에 위치되어 폐기되었으며 이동된 메소드는 어떤 것도 수행하지 않도록 스텁되어 있습니다.

런타임은 더 이상 개인 응용프로그램의 확보를 지원할 수 없으므로 이전 BootLoader.getRunnable()에 대한 대체가 없습니다. 오히려, 사용자가 플랫폼을 시작할 때 관심있는 응용프로그램을 표시해야 합니다.

필요한 조치: 일반적으로 이 API는 아주 소수의 사용자만 사용합니다(Eclipse 플러그인 내에서는 사용할 수 없습니다). 드물기는 하지만 EclipseStarter에서 해당 메소드를 사용하려면 코드를 채택해야 합니다.

30. 플러그인 내보내기에 플러그인의 JAR이 자동으로 포함되지 않음

영향을 받는 대상: 모든 플러그인.

설명: Eclipse 2.1에서는 플러그인 build.properties의 bin.includes 행에 plugin.xml 파일에 있는 라이브러리 선언의 JAR 목록을 포함할 필요가 없었습니다. 이 JAR은 자유롭게 추가되었습니다. Eclipse 3.0에서는 build.properties의 bin.includes 섹션에 있는 파일 목록이 철저한 목록이므로 플러그인 개발자가 빌드하거나 내보낼 때 플러그인에 포함시키려는 모든 파일을 포함해야 합니다.

필요한 조치: build.properties 파일의 bin.includes 행에 사용자 plugin.xml 파일에 나열된 모든 JAR이 포함되어 있는지 확인하십시오.

31. 런타임 API 다시 내보내기

영향을 받는 대상: 변경된 런타임 API의 요소를 포함하는 API를 노출하는 플러그인.

설명: 다양한 플러그인이 런타임 API의 요소를 포함하는 API를 노출합니다. 여기에 요약된 Eclipse 3.0 런타임 변경사항에 따라, 클라이언트 플러그인은 API에서의 런타임 API 사용을 다시 평가해야 합니다.

필요한 조치: 이 시나리오는 Eclipse 런타임 API가 아주 약간만 변경되므로 꽤 드문 시나리오입니다. 시나리오에 따라 클라이언트는 API를 변경하거나 계속 호환성 계층에 의존해야 합니다.

32. 플랫폼의 플러그인 구문 분석 메소드

영향을 받는 대상: org.eclipse.core.runtime.Platform.parsePlugins(..., Factory)를 사용하는 플러그인.

설명: org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) 메소드가 이동되었습니다. 팩토리 인수와 연관되는 API는 org.eclipse.core.runtime 플러그인에서 org.eclipse.core.runtime.compatibility 플러그인(런타임 플러그인에 의존하는)으로 이동되었습니다. 결국, 구문 분석 메소드도 이동되었습니다.

필요한 조치: 이 메소드의 사용자는 org.eclipse.core.runtime.model.PluginRegistryModel 클래스에서 동일 메소드를 사용해야 합니다.

33. 단편으로 제공되는 플러그인 라이브러리

영향을 받는 대상: 클래스 경로에 코드를 지정하지만 해당 코드를 제공하지는 않는 플러그인(즉, JAR이 하나의 단편으로 제공됩니다. 예: org.eclipse.swt 플러그인).

설명: 새 런타임은 상황 뒤에서 plug.xml 파일을 manifest.mf 파일로 변환해야 합니다. 이는 플러그인이 제공하는 나열된 jar의 직접적인 기계적 변환 및 분석을 통해 수행됩니다. 플러그인이 클래스 경로에 jar을 지정하지만 jar을 제공하지는 않는 경우, 분석할 코드가 없으므로 플러그인 변환기는 올바른 manifest.mf를 생성할 수 없습니다.

필요한 조치: 이와 같은 플러그인의 제공자는 플러그인 자체에서 적절한 jar을 제공하거나 플러그인에 맞는 META-INF/MANIFEST.MF 파일을 직접 작성/유지보수하도록 변경해야 합니다. 일반적으로 이는 PDE를 통해 초기 Manifest를 가져온 후 적절한 Provide-Package 헤더에 추가하여 수행할 수 있습니다.

34. 빌드 스크립트 변경사항

영향을 받는 대상: 런타임 관련 jar 및 클래스 디렉토리를 포함하는 클래스 경로를 정의하는 스크립트(예: Ant build.xml 파일).

설명: 새 런타임에는 여러 가지의 새로운 플러그인과 jar이 있습니다. 이 플러그인과 jar은 런타임을 구성 가능 부분들로 리팩토링함에 따라 지정되었습니다. 대부분의 런타임 상황에서는 이 변경사항이 평이하지만 현재 org.eclipse.core.runtime에 대해 코드를 컴파일하는 사용자 정의 build.xml(또는 유사한) 스크립트가 있는 경우에는 먼저 갱신해야 올바르게 작동합니다. 일반적인 스크립트에는 다음과 같이 org.eclipse.core.runtime 플러그인을 참조하는 <javac> 타스크에 클래스 경로 항목이 있습니다.

    ../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar

런타임 플러그인은 계속해서 원래 런타임 코드 중 많은 것을 포함합니다. 그러나 런타임에서 호환성 목적만을 위한 다양한 파트가 호환성 플러그인(org.eclispe.core.runtime.compatibility)에 포함됩니다. 대부분의 새 런타임 코드는 플러그인 콜렉션(org.eclipse.osgi.*)에 포함됩니다.

필요한 조치: 개발자는 컴파일 오류를 제거하기 위해 필요한 만큼 아래 항목을 추가해햐 합니다. 제공된 전체 jar 세트가 아래에 나열되어 있지만 일반적 사용에서는 컴파일 시 클래스 경로에서 하나의 서브세트만 필요합니다. 일반적인 경우처럼 /bin 디렉토리 포함은 임의적입니다. 항목은 플러그인을 제공하여 논리 그룹으로 제공됩니다.

또한 다음 jar이 특수한 경우에 필요할 수 있습니다.

이와 같은 스크립트를 갱신하는 동안, org.eclipse.core.boot에 대한 참조를 정리(제거)할 기회를 만들어야 합니다. 이 플러그인은 폐기되어 더 이상 어떤 코드도 포함하지 않습니다. 항목은 클래스 경로에 남겨 둘 수 있지만 어떤 목적도 제공하지 않으므로 제거해야 합니다. 다음 제거에 주의하십시오.

    ../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar

35. PDE 빌드 Ant 타스크 변경사항

영향을 받는 대상: eclipse.buildScript 타스크를 사용하는 스크립트(예: Ant build.xml 파일).

설명: PDE 빌드는 플러그인 빌드 스크립트 생성을 제어하기 위해 eclipse.buildScript 타스크에 새 특성을 도입했습니다. 이는 새로운 OSGi 기반 런타임 도입으로 지정되었습니다.

필요한 조치: Eclipse 3.0을 사용하여 2.1 기반 제품을 빌드하려면 eclipse.buildScript에 특성 "buildingOSGi"를 도입한 후 false로 설정하십시오. 예를 들어,

<eclipse.buildScript ... buildingOSGi="false"/>

36. eclipse.build Ant 타스크 변경사항

영향을 받는 대상: eclipse.buildScript 타스크를 사용하는 스크립트(예: Ant build.xml 파일).

설명: PDE 빌드는 플러그인 빌드 스크립트 생성을 제어하기 위해 eclipse.buildScript 타스크에 새 특성을 도입했습니다. 이는 새로운 OSGi 기반 런타임 도입으로 지정되었습니다.

필요한 조치: Eclipse 3.0을 사용하여 2.1 기반 제품을 빌드하려면 eclipse.buildScript에 특성 "buildingOSGi"를 도입한 후 false로 설정하십시오. 예를 들어,

<eclipse.buildScript ... buildingOSGi="false"/>

37. eclipse.fetch Ant 타스크 변경사항

영향을 받는 대상: eclipse.buildScript 타스크를 사용하는 스크립트(예: Ant build.xml 파일).

설명: PDE 빌드는 자동화된 빌드 스타일에서 Eclipse를 쉽게 빌드하기 위해 eclipse.fetch 타스크의 동작을 변경했습니다. 요소 스타일은 이제 한 번에 하나의 항목만 지원하므로 scriptName은 항상 무시됩니다.

필요한 조치: eclipse.fetch 호출의 "elements" 태그에 항목 목록을 가지고 있으면 eclipse.fetch를 몇 번에 걸쳐 호출하십시오. scriptName을 설치하기 위해 사용할 경우에는 생성되는 페치 스크립트 이름이 항상 "fetch_{elementId}"라는 점에 유의하십시오. 예를 들면 다음과 같습니다.

<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>

위의 URL은 다음과 같이 됩니다.

<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../>
<eclipse.fetch elements="feature@org.eclipse.platform" .../>

38. install.ini 바꾸기

install.ini 파일은 더 이상 포함되지 않습니다. 구성 서브디렉토리에 새로운 config.ini 파일이 있습니다. 기본 기능을 지정하기 위해 install.ini 파일을 사용한 제품(예: 브랜딩 정보를 제공하기 위함)은 대신 config.ini 파일을 변경해야 합니다. 새 파일 이름 이외에 키 이름도 변경되었습니다.

2.1에서 feature.default.id 키의 값은 새 eclipse.product 키의 값으로 설정해야 합니다. eclipse.application의 값은 "org.eclipse.ui.ide.workbench"로 설정해야 합니다.

마지막으로, 2.1에서는 스플래시 이미지에 대한 이미지가 항상 브랜딩 플러그인 디렉토리에 있는 splash.bmp였습니다. 3.0에서는 스플래시 이미지의 위치가 config.ini 파일에서 osgi.splashPath 키에 의해 명시적으로 제공됩니다.