Inkompatibilitet mellem Eclipse 2.1 og 3.0

Eclipse er ændret fra 2.1 til 3.0 på en måde, som påvirker plugins. Indgangene nedenfor beskriver de områder, der er ændret, og giver en vejledning i, hvordan man overfører 2.1-plugins til 3.0. Bemærk, at du kun behøver læse disse oplysninger, hvis du får problemer med at udføre 2.1-plugins i 3.0.

  1. Plugin-manifest-version
  2. Omstrukturering af platforms-UI-plugins
  3. Omstrukturering af platformens centrale runtime-plugins
  4. Fjernelse af Xerces-plugin
  5. Eclipse 3.0 er mere samtidig
  6. Åbning af editorer for IFiles
  7. Editor - goto-markering
  8. Editor - startprogram
  9. Editor - registreringsdatabase
  10. Arbejdsbænkmarkering - hjælperegistreringsdatabase
  11. Teksteditor - dokumentudbydere
  12. Teksteditorer
  13. Understøttelse af hovedløs annotation
  14. Oversigten Konsol
  15. Java-breakpoint-lytteprogrammer
  16. Udklipsholderadgang i UI-programdel
  17. Tast-ned - aktiviteter
  18. Tabulatorgennemgang af tilpassede kontroller
  19. Valg af aktivitetsrækkefølge i SWT-tabel og træelementer
  20. Nyt niveau i statusobjekter
  21. Beskeder om byggerelateret ressourceændring
  22. Mellemliggende meddelelser i løbet af arbejdsområdefunktioner
  23. URL-strømbehandlerudvidelser
  24. Rækkefølge af klasseindlæsning
  25. Beskyttelsesdomæne for klasseindlæsning ikke angivet
  26. Konvertering af PluginModel-objekt
  27. Implementering af ILibrary ikke udført
  28. Ugyldige antagelser vedr. URL-format
  29. BootLoader-metoder flyttet/slettet
  30. Plugin-eksport omfatter ikke automatisk plugin'ens JAR'er
  31. Eksport af runtime-API igen
  32. Plugin-analysemetoder på platform
  33. Plugin-biblioteker leveret af fragmenter
  34. Ændringer til byggekommandofiler
  35. Ændringer til PDE-bygget Ant-opgave
  36. Ændringer i eclipse.build-Ant-opgave
  37. Ændringer i eclipse.fetch-Ant-opgaver
  38. Udskiftning af install.ini

1. Plugin-manifest-version

Headeren i manifestfilerne til plugins (og plugin-fragmenter) er ændret, så den indeholder en ny linje, der identificerer den relevante plugin-manifest-version. Før 3.0-versionen indeholdt plugins ikke en af linjerne <?eclipse ...?>. Efter 3.0 skal du altid have en sådan linje. Ændringen skal gøre det muligt for Eclipse-runtime at genkende plugins fra før version 3.0, som ikke er overført til 3.0, og dermed automatisk stille større, binær kompatibilitet til rådighed for sådanne plugins. Sådan er ser filen plugin.xml normalt ud (fragment.xml er magen til):

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

Plugin-manifester, der er oprettet ved hjælp af PDE 3.0, har automatisk dette format. Det anbefales kraftigt, at du bruger PDE plugin-overførselsværktøjet. Det indsætter automatisk den angivne linje i manifestet for 2.1-plugins og plugin-fragmenter, samt tager sig af mange af de andre ændringer, der er beskrevet her.

Hvis du føjer direktivet til en plugin.xml (manuelt eller ved hjælp af PDE), skal filen også opdateres, så den eksplicit viser de plugins, den er afhængig af. Før Eclipse 3.0 var org.eclipse.core.runtime- og org.eclipse.core.boot-afhængigheder implicitte. Med 3.0 behøves org.eclipse.core.boot ikke længere, og udviklere skal vælge org.eclipse.core.runtime eller org.eclipse.core.runtime.compatibility (eller ingen af dem), alt efter hvad der er relevant.

Bemærk: Dette er en af de imkompatibiliteter, som ikke påvirker, hvordan Eclipse 3.0 udfører binære 2.1-plugins.

2. Omstrukturering af platforms-UI-plugins

Den org.eclipse.ui-plugin, som før i tiden var det primære platforms-UI-plugin, leverer nu blot API og udvidelsespunkter til den generiske (dvs. ikke-IDE-specifikke) arbejdsbænk. Valgfri og IDE-specifikke API og udvidelsespunkter er flyttet til andre plugins.

Denne ændring betyder to ting: (1) de flyttede org.eclipse.ui-udvidelsespunkter har nye udvidelsespunkt-id'er, og (2) listen med nødvendige plugins er ændret.

Org.eclipse.ui-udvidelsespunkterne i følgende tabel er flyttet til andre plugins, hvilket ændrer deres udvidelsespunkt-id'er. Hvis en eksisterende plugin bidrager med en udvidelse til de flyttede udvidelsespunkter, skal referencen i "point"-attributten i <extension>-elementet i plugin-manifest-filen ændres, så den henviser til de tilsvarende nye udvidelsespunkt-id'er. PDE-plugin-overførselsværktøjet foretager disse rettelser.

Bemærk: Dette er en af de imkompatibiliteter, som ikke påvirker, hvordan Eclipse 3.0 udfører binære 2.1-plugins. Eclipse 3.0-runtime registrerer automatisk plugins fra før version 3.0 (på grund af den manglende <?eclipse version="3.0"?>-linje i plugin-manifestet) og kompenserer automatisk for disse ændringer i udvidelsespunkter og plugin-afhængigheder.

Gammel udvidelsespunkt-id

Ny udvidelsespunkt-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

Tabellen nedenfor viser de API-pakker, som tidligere blev leveret af org.eclipse.ui-plugin'en, og som nu er flyttet til andre plugins. (Navnene på API-pakkerne, klasserne, felterne og metoderne er ikke ændret). I nogle tilfælde er API-pakkerne nu fordelt over flere plugins. Da de API-klasser, som en given plugin kan se, bestemmes af den plugins liste med nødvendige plugins, kan ændringerne nødvendiggøre en tilpasning af "<requires>"-elementerne i en eksisterende plugins manifest, for at der igen er adgang til API-klassen.

Denne ændring påvirker kun plugins, som er afhængige af org.eclipse.ui-plugin'en (det vil sige, omfatter <import plugin="org.eclipse.ui"/> i afsnittet <requires> i plugin-manifestet). Ingen andre plugins påvirkes. Hvis en plugin påvirkes, kan det være nødvendigt at ændre <import>-elementet eller at tilføje ekstra <import>-elementer, så alle de API-klasser, plugin'en har brug for, er inden for intervallet. Vi anbefaler kraftigt, at plugins kun angiver afhængigheder på de plugins, som de rent faktisk bruger. Hvis du inkluderer unødvendige afhængigheder, reduceres runtime-ydeevnen, fordi Java-klasseindlæsningsprogrammet skal søge efter klasser i alle afhængigheder. (PDE-plugin-overførselsværktøjet retter afhængighederne og er med til at bestemme et minimalt antal).

API-pakke

2.1-plugin

Tilsvarende 3.0-plugins

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. Omstrukturering af platformens centrale runtime-plugins

Eclipse 3.0 Platform Runtime er baseret på OSGi, hvilket gør det nødvendigt at foretage ændringer i strukturen af de to platforms-runtime-plugins, org.eclipse.core.runtime og org.eclipse.core.boot.

En ny org.eclipse.core.runtime.compatibility-plugin sørger for en implementeringsbro mellem de gamle og de nye API'er og er et nyt hjemsted for mange af de forældede API'er, der tidligere fandtes i org.eclipse.core.runtime og org.eclipse.core.boot. Platforms-runtime-udvidelsespunkter påvirkes ikke af omstruktureringen.

Når du overfører den eksisterende plugin til 3.0, skal plugin'ens manifest opdateres, så den afspejler den nye struktur i Eclipses platform-runtime-plugins. Værktøjet til overførsel af PDE-plugin-manifestet tilføjer om nødvendigt en afhængighed til org.eclipse.core.runtime.compatibility.

Bemærk også, at hvis du markerer en plugin som 3.0 (ved hjælp af <?eclipse version="3.0"?>), og plugin'en definerer en plugin-klasse, skal du enten udtrykkeligt angive <import plugin="org.eclipse.core.runtime.compatibility"/> i plugin-manifestet eller sikre, at plugin-klassen definerer standardkonstruktøren.

Bemærk: Dette er en af de imkompatibiliteter, som ikke påvirker, hvordan Eclipse 3.0 udfører binære 2.1-plugins. Eclipse 3.0-runtime registrerer automatisk plugins fra før version 3.0 (på grund af den manglende <?eclipse version="3.0"?>-linje i plugin-manifestet) og kompenserer automatisk for disse ændringer i platforms-runtime.

4. Fjernelse af Xerces-plugin

Plugin'en org.eclipse.xerces er ikke længere nødvendig og er slettet. XML-analyse-support er bygget ind i J2SE 1.4, og tilstedeværelsen af Xerces-plugin skaber klasseindlæsningskonflikter. API-pakkerne javax.xml.parsers, org.w3c.dom.* og org.xml.sax.*, som tidligere blev leveret af plugin'en org.eclipse.xerces, findes nu i J2SE-bibliotekerne.

Hvis din plugin kræver plugin'en org.eclipse.xerces, skal du ændre manifestet til din plugin, så denne afhængighed fjernes. Når det er gjort, behøver du ikke ændret andet for at kompilere og udføre plugin'ens kode.

En binær 2.1-plugin med en angivet afhængighed af plugin'en org.eclipse.xerces mangler en forudsætning, hvis den udføres i en Eclipse 3.0-standardkonfiguration. Resultatet er, at plugin'en ikke aktiveres.

5. Eclipse 3.0 er mere samtidig

Før Eclipse 3.0 fungerede Eclipse primært i en enkelt programdel. De fleste API-metoder og udvidelsespunkter fungerer enten i UI-programdelen eller i en programdel, der produceres fra en statusdialogboks, som har blokeret UI-programdelen. De fleste plugin-skrivefunktioner behøvede ikke bekymre sig synderligt om programdelssikkerhed, bortset fra at sikre sig, at alle UI-aktiviteter forekom i UI-programdelen. I Eclipse 3.0 er der generelt en meget højere grad af samtidighed. Mange funktioner udføres nu i en baggrundsprogramdel, hvor de kan udføres samtidigt med andre programdele, herunder UI-programdelen. Alle de plugins, hvis kode udføres i en baggrundsprogramdel, skal nu være opmærksomme på programdelssikkerheden for deres kode.

Ud over plugins, som specifikt udfører funktioner i baggrunden ved hjælp af API'et org.eclipse.core.runtime.jobs, er der adskillige API-platformsaktiviteter og -udvidelsespunkter, som benytter baggrundsprogramdele. Plugins, som et koblet på disse faciliteter, skal sikre, at deres kode er sikker, for så vidt angår programdele. Nedenstående tabel giver en oversigt over API'et og de udvidelsespunkter, som udfører noget af eller hele deres kode i en baggrundsprogramdel i Eclipse 3.0:

Udvidelsespunkt eller API-klasse

Bemærkninger

org.eclipse.core.runtime.IRegistryChangeListener Ny i Eclipse 3.0, udføres i baggrunden
org.eclipse.core.resources.IResourceChangeListener AUTO_BUILD-aktiviteter nu i baggrunden
org.eclipse.core.resources.builders (udv.punkt) Bygges nu automatisk i baggrunden
org.eclipse.core.resources.ISaveParticipant SNAPSHOT nu i baggrunden
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (udv.punkt) Ny i Eclipse 3.0, udføres i baggrunden
org.eclipse.ui.decorators (udv.punkt) Allerede i baggrunden i Eclipse 2.1
org.eclipse.ui.startup (udv.punkt) Allerede i baggrunden i Eclipse 2.1
org.eclipse.team.core.org.eclipse.team.core.repository (udv.punkt) Mange funktioner nu i baggrunden
org.eclipse.team.ui.synchronizeParticipants (udv.punkt) Ny i Eclipse 3.0, udføres i baggrunden
org.eclipse.debug.core.launchConfigurationTypes (udv.punkt) Udføres nu i baggrunden
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD udføres nu i baggrunden, POST_RECONCILE blev allerede udført i baggrunden

Der findes flere strategier, der kan benyttes til at sikre kodeprogramdele. Den enkleste løsning er at sikre, at alt arbejde forgår i UI-programdelen, og på den måde sikre en serialiseret udførelse. Det er en almindelig løsning i forbindelse med UI-plugins, som ikke foretager CPU-intensiv databehandling. Hvis du vælger denne løsning, skal du være opmærksom på risikoen for baglås, som ligger i Display.syncExec. Det er generelt sikrere at benytte Display.asyncExec, fordi den ikke indfører risiko for baglås, til gengæld har du ikke nøjagtig kontrol over, hvornår koden udføres.

Andre teknikker til sikring af programdelskode:

6. Åbning af editorer for IFiles

Følgende metoder er slettet fra org.eclipse.ui.IWorkbenchPage-grænsefladen. IWorkbenchPage er erklæret i den generiske arbejdsbænk, men metoderne er ressourcespecifikke.

Klienter til disse IWorkbenchPage.openEditor-metoder skal i stedet kalde de tilsvarende offentlige, statiske metoder, der er erklæret i klassen org.eclipse.ui.ide.IDE (i plugin'e org.eclipse.ui.ide).

Klienter til denne IWorkbenchPage.openSystemEditor(IFile)-metode skal konvertere IFile til en IEditorInput ved hjælp af en ny FileEditorInput(IFile) og derefter kalde metoden openEditor(IEditorInput,String). Det vil sige omskrive page.openSystemEditor(file) som page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Bemærk: Klienter, der benytter editor-id'en IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID, skal overføre et editor-input, der implementerer org.eclipse.ui.IPathEditorInput (hvilket FileEditorInput gør).

Bemærk: Dette er en af de imkompatibiliteter, som ikke påvirker, hvordan Eclipse 3.0 udfører binære 2.1-plugins. Eclipse 3.0 indeholder en binær runtime-kompatibilitetsmekanisme, som ved hjælp af en af de slettede openEditor- og openSystemEditor-metoder sikrer, at eksisterende binære 2.1-plugins fortsat arbejder som i 2.1 til trods for denne API-ændring. (De slettede metoder tilføjes effektivt "tilbage igen" via fragmentet org.eclipse.ui.workbench.compatibility).

7. Editor - goto-markering

Nedenstående metode er slettet fra org.eclipse.ui.IEditorPart-grænsefladen. IEditorPart er erklæret i den generiske arbejdsbænk, men metoden er ressourcespecifik.

De tilsvarende metoder blev også slettet fra klasserne i pakken org.eclipse.ui.part, som implementerer IEditorPart, nemlig EditorPart, MultiEditor, MultiPageEditorPart og MultiPageEditor. 

Klienter, som kalder denne metode, skal i stedet teste, om editordelen implementerer eller tilpasses til org.eclipse.ui.ide.IGotoMarker (i plugin'en org.eclipse.ui.ide). Gør den det, skal du kalde gotoMarker(IMarker). IDE-klassen har en metode, der kan benyttes til det: IDE.gotoMarker(editor, marker);

Klienter, som implementerer en editor, der kan placere sig selv på basis af IMarker-oplysninger, skal implementere eller tilpasses org.eclipse.ui.ide.IGotoMarker.

Da IGotoMarkers eneste metode er gotoMarker(IMarker) og har samme signatur og specifikation som den gamle IEditorPart.gotoMarker(IMarker), kan eksisterende editorimplementeringer tilpasses denne ændring ved simpelthen at inkludere IGotoMarker i implementeringsudtrykket i klassedefinitionen.

En binær 2.1-plugin med kode, som kalder denne metode, får en klassesammenkædningsfejl, hvis den udføres i en Eclipse 3.0-standardkonfiguration.

8. Editor - startprogram

Grænsefladen org.eclipse.ui.IEditorLauncher til editorstartprogrammet implementeres ved hjælp af plugins, som bidrager med eksterne editorer. Følgende metode er fjernet fra denne grænseflade. IEditorLauncher er erklæret i den generiske arbejdsbænk, men metoden er ressourcespecifik.

Den er erstattet af

Klienter, som kalder IEditorLauncher.open(file), skal i stedet kalde IEditorLauncher.open(file.getLocation()). Klienter, som implementerer denne grænseflade, skal erstatte (eller øge) deres implementering af open(IFile) med én for open(IPath).

En binær 2.1-plugin med kode, som kalder denne metode, får en klassesammenkædningsfejl, hvis den udføres i en Eclipse 3.0-standardkonfiguration.

9. Editor - registreringsdatabase

Nedenstående metoder er fjernet fra grænsefladen org.eclipse.ui.IEditorRegistry. IEditorRegistry er erklæret i den generiske arbejdsbænk, men metoderne er ressourcespecifikke.

Klienter, der kalder getEditors(file) eller getImageDescriptor(file), skal kalde de "String"-tilsvarende metoder: Klienter, som kalder setDefaultEditor(IFile file, String editorId) og getDefaultEditor(IFile file), skal i stedet kalde de tilsvarende public static-metoder, der er erklæret i klassen org.eclipse.ui.ide.IDE (i plugin'en org.eclipse.ui.ide): API-kontrakten til metoden IEditorRegistrygetDefaultEditor() er ændret. Denne metode, som også nu er forældet, vil altid returnere editordeskriptoren System External Editor. Denne ændring påvirker klienter, som antog, at den standardeditor, der blev returneret, var en teksteditor.

Der er nye konstanter, som repræsenterer de systemeksterne og systeminterne editor-id'er (SYSTEM_EXTERNAL_EDITOR_ID og SYSTEM_INPLACE_EDITOR_ID). Disse to editorer kræver et editorinput, som implementerer eller tilpasses til org.eclipse.ui.IPathEditorInput. Bemærk, at den interne editordeskriptor ikke findes i Eclipse-konfigurationer, som ikke understøtter intern redigering.

10. Arbejdsbænkmarkering - hjælperegistreringsdatabase

Nedenstående metode er slettet fra grænsefladen org.eclipse.ui.IWorkbench. IWorkbench er erklæret i den generiske arbejdsbænk, men metoden er ressourcespecifik.

IWorkbench.getMarkerHelpRegistry()-klienter skal i stedet kalde public static-metoden org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (i plugin'en org.eclipse.ui.ide).

En binær 2.1-plugin med koden, som kalder denne metode, modtager en undtagelse, når den udføres i en Eclipse 3.0-standardkonfiguration.

11. Teksteditor - dokumentudbydere

For at gøre org.eclipse.ui.texteditor.AbstractTextEditor uafhængig af IFile introducerer org.eclipse.ui.texteditor.AbstractDocumentProvider begreberne dokumentudbyderfunktion (DocumentProviderOperation) og dokumentudbyderfunktionsrunner (IRunnableContext). Når AbstractDocumentProvider bliver bedt om at nulstille, gemme eller synkronisere, opretter den dokumentudbyderfunktioner og benytter funktionsrunner'en til at udføre dem. Den kontekst, der kan udføres, kan leveres af underklasser via getOperationRunner-metoden. Her er en oversigt over de ændringer, som klienterne skal tilpasses:

AbstractDocumentProvider-underklassen org.eclipse.ui.editors.text.StorageDocumentProvider implementerer metoden getOperationRunner, så den altid returnerer null. Det betyder, at underklasser af StorageDocumentProvider ikke påvirkes af denne ændring.

StorageDocumentProvider-underklassen org.eclipse.ui.editors.text.FileDocumentProvider implementerer metoden getOperationRunner, som returnerer en IRunnableContext, for at udføre den givne DocumentProviderOperations i en WorkspaceModifyOperation. Andre ændringer til FileDocumentProvider er:

12. Teksteditorer

Ændringer til org.eclipse.ui.texteditor.AbstractTextEditor:

AbstractTextEditor-underklassen org.eclipse.ui.texteditor.StatusTextEditor stiller prædikatmetoden isErrorStatus(IStatus) til rådighed. Underklasser kan tilsidesætte for at bestemme, om en given status skal betragtes som en fejl eller ej.

Ændringer til org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:

13. Understøttelse af hovedløs annotation

Som en del af indførelsen af understøttelse af hovedløs annotation skal følgende ændringer foretages til annotationen:

        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. Oversigten konsol

Eclipse 3.0 har ny generisk konsolunderstøttelse. Den generiske konsol er tilgængelig via Vindue > Vis oversigt > Basis > Konsol og bruges af Eclipse-fejlfindingsfunktioner og Ant-integration.

Oversigts-id'en til konsollen er ændret fra org.eclipse.debug.ui.ConsoleView til org.eclipse.ui.console.ConsoleView. 2.1-plugins, som rent programmeringsmæssigt åbner konsollen, kan ikke bruges, fordi den gamle oversigt ikke længere findes.

15. Java-breakpoint-lytteprogrammer

I 3.0 er returtyperne for metoderne org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) og installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) ændret fra boolean til int for at tillade, at lytteprogrammerne kan vælge "don't care". I releases før 3.0 kunne lytteprogrammerne kun vælge "suspend" eller "don't suspend", når de ramte et breakpoint, og "install" eller "don't install", når et breakpoint skulle installeres. I version 3.0 kan lytteprogrammer også vælge "don't care" til disse meddelelser. På den måde behøver klienterne kun træffe en endelig afgørelse i de situationer, de skal bruge til noget. I tilfælde af meddelelser af typen "breakpoint hit" afbrydes breakpoint midlertidigt, hvis et lytteprogram vælger "suspend", eller hvis alle lytteprogrammer vælger "don't care";. Breakpoint'et afbrydes ikke midlertidigt, hvis mindst ét lytteprogram vælger "don't suspend" og ingen lytteprogrammer vælger "suspend". På samme måde gælder det for meddelelser af typen "breakpoint installing", at breakpoint'et installeres, hvis et lytteprogram vælger at installere, eller hvis alle lytteprogrammer vælger "don't care". Breakpoint'et installeres ikke, hvis mindst et lytteprogram vælger "don't install" og ingen lytteprogrammer vælger "install". Generelt returnerer implementorer DONT_CARE, medmindre de er helt klar over, hvad de ellers skal vælge. Det er vigtigt at huske på, at f.eks. "suspend" tilsidesætter andre lytteprogrammers valg af "don't suspend".

Grænsefladen IJavaBreakpointListener implementeres af klienter, der opretter eller reagerer på breakpoints i Java-kode. Der er kun få klienter ud over JDT selv, bortset fra den klient der har rapporteret problemet (bug 37760), som denne ændring retter op på. Det er en vigtig ændring i den eksisterende kode, som implementerer IJavaBreakpointListener-grænsefladen. Koden skal ændres, så den returnerer en korrekt int-værdi, før den kan kompileres eller udføres i 3.0.

16. Udklipsholderadgang i UI-programdel

Før 3.0 kunne SWT-klassen org.eclipse.swt.dnd.Clipboard godt udføres i andre programdele end UI-programdelen. Denne forglemmelse gav fejl i GTK, hvor styresystemet kræver, at alle udklipsholderfunktioner udføres i UI-programdelen. Forglemmelsen er ikke kommet frem før, fordi mange programmer består af én programdel og primært testes på Windows. For at udklipsholder-API'et kan understøttes og udføres på flere platforme, er specifikationerne til og implementeringen af alle udklipsholder-API-metoderne i 3.0 ændret, så de giver en SWT-undtagelse (ERROR_THREAD_INVALID_ACCESS), hvis de startes fra en ikke-UI-programdel. Udklipsholderydelser stilles normalt automatisk til rådighed af Eclipse-komponenter, f.eks. teksteditoren, der isolerer mange klienter fra denne vigtige ændring. Eksisterende kode, som direkte bruger udklipsholderen, skal sikre, at API-metoderne kaldes i den korrekte programdel, ved hjælp af Display.asyncExec eller syncExec, når der skal ændres adgang til UI-programdelen.

17. Tast-ned-aktiviteter

I 3.0 rapporterer SWT tast-ned-aktiviteter, før arbejdet udføres i styresystemet. Det er meget tidligere end i de versioner, der ligger før 3.0. Denne ændring e foretaget for at understøtte tastbindinger i Eclipse, der gør det nødvendigt at opfange tastaktiviteter, før et element får chancen for at behandle tegnet. Konsekvenserne af denne ændring kan ses af kode, der håndterer lavniveaus-org.eclipse.swt.SWT.KeyDown-aktiviteter direkte. Det betyder f.eks., at når et lytteprogram på et tekstelement modtager en tast-ned-aktivitet, inkluderer elementets indhold (getText()) endnu ikke den tast, der netop er angivet, hvilket det ville have gjort før 3.0. Den anbefalede måde at få den fulde tekst fra elementet, herunder den aktuelle tast, er at håndtere SWT.Modify- eller SWT.Verify-aktiviteterne (der har et højere niveau) i stedet for lavniveau-SWT.KeyDown-aktiviteten. Kode, der allerede opfører sig på denne måde, påvirkes ikke af ændringen.

18. Tabulatorgennemgang af tilpassede vindueslementer

Når fokus før 3.0 var på SWT-klassen org.eclipse.swt.widgets.Canvas eller en af dens underklasser (herunder tilpassede elementer), og man trykkede på Ctrl+Tab, Shift+Tab, Ctrl+PgUp eller Ctrl+PgDn, hoppede man automatisk til det næste/forrige element, uden at tastaktiviteterne blev rapporteret. Denne funktionsmåde er ikke-specificeret og går imod den regel, at Canvases ser alle de taster, der benyttes i dem. Den korrekte måde at håndtere en gennemgang på er at registrere et gennemgangslytteprogram. For at kunne understøtte Eclipse-tastbindinger korrekt i 3.0 er standardfunktionsmåden ændret, så Canvas nu ser tastaktiviteterne Ctrl+Tab, Shift+Tab, Ctrl+PgUp og Ctrl+PgDn i stedet for en gennemgang. Hvis du bruger en rå Canvas eller definerer en underklasse af Canvas, skal du sørge for at registrere et gennemgangslytteprogram.

19. Valg af aktivitetsrækkefølge i SWT-tabel og træelementer

Valg med musen af elementer i SWT-klasserne org.eclipse.swt.widgets.Table og Tree genererer aktivitetsrækkefølgen MúsNed-Valg-MusOp ensartet i alle styresystemer. På samme måde genererer tastaturvalg aktivitetsrækkefølgen TastNed-Valg-TastOp ensartet i alle styresystemer. Før 3.0 var aktivitetsrækkefølgen ikke ensartet med Motif og Photon i modstrid med resten, fordi de altid rapporterede Valg-aktiviteten først, dvs. Valg-MusNed-MusOp eller Valg-TastNed-TastOp. I 3.0 er aktivitetsrækkefølgen for Motif og Photon ændret, så den matcher de andres. Eksisterende kode, som fungerede korrekt på {Windows, GTK} og på {Motif, Photon} påvirkes sandsynligvis ikke. Men det er klogt at tjekke koden for at sikre, at den ikke baserer sig på en ugyldig aktivitetsrækkefølge.

20. Nyt niveau i statusobjekter

org.eclipse.core.runtime.IStatus har en ny niveaukonstant, IStatus.CANCEL, der kan bruges til at angive annullering. Kaldere til IStatus.getSeverity(), som regner med at mulige niveauer er begrænset til IStatus.OK, INFO, WARNING og ERROR, påvirkes af denne tilføjelse. Kaldere til getSeverity skal opdatere koden, så den omfatter det nye niveau.

21. Beskeder om byggerelateret ressourceændring

I Eclipse 3.0 sker automatisk arbejdsområdebygning nu i en baggrundsprogramdel. Det forudsatte en API-kontraktændring til org.eclipse.core.resources.IResourceChangeEvent. Kontrakten IResourceChangeEvent garanterede tidligere følgende rækkefølge af aktiviteter for alle arbejdsområdeændringer:

  1. Meddelelse om PRE_DELETE- eller PRE_CLOSE-aktivitet, hvis relevant.
  2. Udfør funktionen.
  3. Meddelelse om PRE_AUTO_BUILD-aktivitet.
  4. Foretag trinvis bygning af arbejdsområde, hvis automatisk bygning er aktiveret.
  5. Meddelelse om POST_AUTO_BUILD-aktivitet.
  6. Meddelelse om POST_CHANGE-aktivitet.

Når automatisk bygning udføres i baggrunden, er der ikke længere nogen garanti med hensyn til den tidsmæssige relation mellem AUTO_BUILD-aktiviteterne og POST_CHANGE-aktiviteten. I Eclipse 3.0 er trin 3-5 i strukturen ovenfor fjernet fra funktionen. Det deraf følgende billede ser ud som følger:

  1. Meddelelse om PRE_DELETE- eller PRE_CLOSE-aktivitet, hvis relevant.
  2. Udfør funktionen.
  3. Meddelelse om POST_CHANGE-aktivitet.

Med jævne mellemrum fortager platformen en byggefunktion i baggrunden for arbejdsområdet. Bemærk, at det sker, uanset om automatisk bygning er aktiveret eller ej. Præcis hvornår denne bygning forekommer, angives ikke. Byggefunktionens struktur ser ud som følger:

  1. Meddelelse om PRE_BUILD-aktivitet (PRE_BUILD er det nye navn for PRE_AUTO_BUILD)
  2. Foretag trinvis bygning af arbejdsområde, hvis automatisk bygning er aktiveret.
  3. Meddelelse om POST_BUILD-aktivitet (POST_BUILD er det nye navn for POST_AUTO_BUILD)
  4. Meddelelse om POST_CHANGE-aktivitet.

Referencepunktet for de deltaer, som lytteprogrammerne for automatisk bygning modtager, er forskellige fra lytteprogrammerne efter ændringen. Byggelytteprogrammer modtager meddelelse om alle ændringer siden afslutningen af den sidste byggefunktion. Lytteprogrammerne efter ændringen modtager en delta, der beskriver alle de ændringer, der er foretaget siden den sidste meddelelse blev sendt ud efter en ændring. Denne nye struktur beholder tre af de karakteristika fra ressourceændringslytteprogrammerne, som have være sande (true) siden Eclipse 1.0:

Der er dog visse vigtige forskelle. Før Eclipse 3.0 blev lytteprogrammer af typen automatisk bygning altid kaldt før POST_CHANGE-lytteprogrammer. Derfor var den delta, som lytteprogrammerne af typen automatisk bygning modtog, altid en delmængde af den delta, som POST_CHANGE-lytteprogrammerne modtog. Dette forhold er nu vendt om. Lytteprogrammer af typen automatisk bygning modtager en delta, som er et supersæt af alle de delta, som POST_CHANGE-lytteprogrammerne har modtaget, siden den sidste baggrundsbygning blev afsluttet. Som tidligere kan lytteprogrammer af typen automatisk bygning ændre arbejdsområdet, og post-change-lytteprogrammer kan ikke.

Det er ikke længere sådan, at ved afslutningen af en ændring af arbejdsområdet modtager AUTO_BUILD-aktivitetslytteprogrammer en meddelelse. Klientkode, som registrerer ressourceændringslytteprogrammer med IWorkspace.addResourceChangeListener(IResourceChangeListener), påvirkes sandsynligvis ikke af denne ændring, fordi AUTO_BUILD-aktiviteterne aldrig er rapporteret til disse lytteprogrammer. Klienter, som benytter IWorkspace.addResourceChangeListener(IResourceChangeListener,int) og angiver en aktivitetsmaske, som omfatter AUTO_BUILD-aktiviteter, afbrydes sandsynligvis af denne ændring, hvis de fremsætter antagelser om, hvornår byggeprogrammer af typen automatisk bygning udføres, eller hvilken programdel de udføres i. Hvis f.eks. et byggeprogram af typen automatisk bygning opdaterer en domænemodel, så den afspejler ændringer i arbejdsområdet, er denne opdatering eventuelt ikke sket, når ændringsfunktionen for arbejdsområdet vender tilbage. Det er værd at bemærke, at kun kode på UI-niveau kan påvirkes på denne måde. Kode på kerneniveau, som kaldes via API, kan kaldes inde fra en IWorkspaceRunnable, og den kan derfor aldrig være sikker på, hvornår ressourceændringslytteprogrammer bliver kaldt. Den foreslåede rettelse af dette brud er at bruge POST_CHANGE i stedet for byggelytteprogrammer, hvis det er nødvendigt at modtage en meddelelse, før funktionen er udført.

22. Mellemliggende meddelelser i løbet af arbejdsområdefunktioner

Det garanteres ikke længere, at alle ressourceændringer, som indtræffer i løbet af det dynamiske interval for en IWorkspaceRunnable, samles i en enkelt meddelelse. Denne mekanisme kan stadig benyttes til samling af ændringer for at undgå unødvendige byggefunktioner og meddelelser, men platformen kan nu beslutte at udføre meddelelser i løbet af funktionen. Denne API-kontraktændring er sandsynligvis ikke en brudændring for eksisterende klienter. Det svarer til, at platformen beslutter at kalde IWorkspace.checkpoint med jævne mellemrum i løbet af langvarige funktioner. Grunden til denne ændring er, at det nu er muligt, at flere programdele samtidigt kan ændre arbejdsområdet. Når én programdel er færdig med at ændre arbejdsområdet, kræves en meddelelse for at forhindre problemer med lydhørheden, også selvom den anden funktion endnu ikke er færdigudført. Ændringen gør det også muligt for brugerne at begynde at arbejde med en sæt ressourcer, før funktionen er færdigudført. En bruger kan f.eks. begynde at bladre i filer i et projekt, som stadig er ved at blive tjekket ud. Den nye metode IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) har en valgfri markering, AVOID_UPDATE, som funktionerne kan bruge som tip til platformen om at angive, om der ønskes regelmæssige opdateringer.

23. URL-strømbehandlerudvidelser

Hvad påvirkes: Plugin, som bidrager med udvidelser til org.eclipse.core.runtime.urlHandlers-udvidelsespunktet.

Beskrivelse: Kontrakten til org.eclipse.core.runtime.urlHandlers-udvidelsespunktet er ændret, så du kan benytte den URL-strømbehandlerservice, som OSGi tilbyder. OSGi-understøttelsen er bedre end den, der er i Eclipse 2.1, og håndterer dynamiske behandlere korrekt. På grund af forskellige designspørgsmål i forbindelse med basis-Java URL-behandlermekanismen, skal URLStreamHandlers, som er registreret hos OSGi-behandlerservicen, implementere org.osgi.service.url.URLStreamHandlerService.

Påkrævet handling: Tidligere skulle behandlerklassen implementere java.net.URLStreamHandler og udvide urlHandlers-udvidelsespunktet. Udvidelsespunktet understøttes ikke længere, og behandleren skal opdateres for at implementere grænsefladen org.osgi.service.url.URLStreamHandlerService. OSGi-strukturen tilbyder en basisklasse af typen abstract (org.osgi.service.url.AbstractURLStreamHandlerService), som kan angives som underklasse for at udfylde denne rolle.

I stedet for at registrere behandleren vha. et udvidelsespunkt, skal plugins nu registrere deres behandler som en service. For eksempel

    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. Rækkefølge af klasseindlæsning

Hvad påvirkes: Plugins, som leverer pakker, der også leveres af andre plugins. Kun et meget begrænset antal plugins påvirkes af denne ændring, og for nogle af dem, der påvirkes, vil det rent faktisk være en fordel (se nedenfor).

Beskrivelse: I Eclipse 2.x, søger klasseindlæsere efter klasser i følgende rækkefølge: kontakter (1) den overordnede klasseindlæser (i praksis er det Java-start-klasseindlæseren), derefter (2) indholdet af indlæserens egen clsspath og endelig (3) alle dens forudsætninger i den erklærede rækkefølge. OSGi tilbyder en optimalisering over denne model. I dette tilfælde kontakter klasseindlæseren (1) den overordnede klasseindlæser (igen, rent faktisk Java-start-klasseindlæseren), og derefter enten (2a) en enkel forudsætning, som vides at bidrage med klasser i den pakke, der bliver forespurgt på, eller (2b) sine egne classpath-indgang for den ønskede klasse.

Klasseindlæseren bestemmer, om den skal kontakte sig selv eller sine forudsætninger baseret på de importerede og krævede pakker. Oplysningerne udledes af plugin-indholdet i tilfælde af traditionelle plugins, og angives direkte i tilfælde af plugins med eksplicit OSGi-bundt-manifest. I begge tilfælde vides det a priori, hvilke klasseindlæsere der leverer klasserne til hvilke pakker. Det betyder forbedring af ydeevnen samt en løsning på problemet med, at flere forudsætninger bidrager til de samme klasser.

Tag f.eks. tilfældet med Xerces og Xalan som begge indeholder forskellige klasser fra org.xml-pakkerne. Hvis du bruger den første metode, får Xerces-plugin vist sin kopi af disse klasser, mens Xalan-plugin får vist sin kopi. Da disse plugins skal kunne kommunikere, indtræffer en ClassCastExceptions. Hvis du bruger den anden metode, bidrager kun en af de to plugins med de samme klasser, og begge plugins får vist de samme kopier.

Påkrævet handling: Den påkrævede handling afhænger af de nærmere oplysninger om usecase. De berørte udviklere skal gennemgå deres classpath og løse eventuelle konflikter, som kan opstå.

25. Beskyttelsesdomæne for klasseindlæsning ikke angivet

Hvad påvirkes: Plugins, som forventer, at beskyttelsesdomænet for deres klassindlæser er angivet altid.

Beskrivelse: I Eclipse 2.1, var plugin-klasseindlæserne java.security.SecureClassloaders, og de havde som sådan altid angivet et beskyttelsesdomæne. I Eclipse 3.0 udvider klasseindlæserne ikke SecureClassloader og angiver kun beskyttelsesdomænet, hvis Java-sikkerhed er aktiveret (hvad det ikke er normalt).

Påkrævet handling: Den nødvendige handling afhænger af det scenarie, hvori plugin'en bruger beskyttelsesdomænet.

26. Konvertering af PluginModel-objekt

Hvad påvirkes: Plugins, som konverterer objekter af typen org.eclipse.core.runtime.IPlugin* til org.eclipse.core.runtime.model.Plugin*Model. Selvom forholdet mellem disse grænseflader og modelklasserne ikke er angivet i Eclipse 2.1-API'et, henleder vi eksplicit opmærksomheden på denne ændring, fordi vi har fundet tilfælde, hvor plugins forudsætter denne relation i 2.1-implementeringen.

Beskrivelse: Eclipse-API stiller en række grænseflader til rådighed, f.eks. IPluginDescriptor, og såkaldte "model"-klasser, f.eks. PluginDescriptorModel, som relaterer sig til plugins og plugin-registreringsdatabasen. I Eclipse 2.1-implementeringen kan man komme ud for, at modelklasserne implementerer de relevante grænseflader. I den nye OSGi-baserede runtime er plugin-registreringsdatabasen omarbejdet betydeligt for at tage højde for en adskillelse mellem klassindlæsningsaspekterne og de nødvendige aspekter ved plugins og udvidelses- og udvidelsespunktaspekterne. Eclipse 3.0-runtime er som sådan ikke i stand til at opretholde det implementeringsforhold, som var i 2.1.

Påkrævet handling: Plugins, som anvender denne ikke-API-relation, skal være omarbejdet kode i henhold til deres usecase. Der er flere oplysninger herom i afsnittet om anbefalede ændringer i dette dokument og i Javadoc til de relaterede klasser og metoder.

27. Implementering af ILibrary ikke udført

Hvad påvirkes: Plugins, som benytter org.eclipse.core.runtime.ILibrary.

Beskrivelse: Ny runtime opretholder classpath-indgange i et anderledes format, der er inkompatibel med Eclipse. Resultatet er, at kompatibilitetslaget ikke kan vise en korrekt model af de underliggende OSGi-strukturer som ILibrary-objekter. Runtimes kompatibilitetsunderstøttelse opretter ILibrary-objekter, men skal forudsætte standardværdier for alt bortset fra bibliotekets sti.

Påkrævet handling: Brugere af ILibrary bør overveje at få adgang til de ønskede header-værdier, f.eks. Bundle-Classpath, fra det relevante Bundle (se Bundle.getHeaders()) og bruge ManifestElement-hjælpeklassen til at fortolke indgangene. Der er flere oplysninger i klassen Javadoc.

28 Ugyldige antagelser vedr. URL-format

Hvad påvirkes: Plugins, der fremsætter forudsætninger vedrørende deres installationsstruktur, placering og layout for det lokale filsystem.

Beskrivelse: Metoder, f.eks. IPluginDescriptor.getInstallURL(), returnerer URL-adresser i et bestemt format. Selvom formatet ikke er angivet, fremsætter forskellige plugins forudsætninger baseret på den aktuelle implementering. De forventer f.eks. at modtage en fil:URL og bruge URL.getFile() og bruge java.io.File-manipulation på resultatet. Indtil nu har denne fremgangsmåde fungeret, selvom den har været ret skrøbelig. Hvis en plugin f.eks. er installeret på en webserver, er det muligt, at der returneres en http:URL. Den nye Eclipse 3.0-runtime er endnu mere fleksibel og åbner mulighed for udførelseskonfigurationer, f.eks. vedligeholdelse af plugins i JAR-filer i stedet for sprede dem ud på biblioteker. Det vil sige, at mens den nye OSGi-baserede runtime ikke afbryder 2.1-API'et, så afslører den flere tilfælde, hvor forudsætninger, der er forudsat i de aktuelle plugins, er ugyldige.

Påkrævet handling: Plugin-skrivefunktionerne skal sikre, at der er adgang til de oplysninger, som de skal bruge, via getResource() (og at de er på classpath), eller de skal bruge den relevante API for at få adgang til indholdet af en plugin, f.eks. Bundle.getEntry(String).

29. BootLoader-metoder flyttet/slettet

Hvad påvirkes: Ikke-plugin-kode, som kalder visse metoder fra klassen org.eclipse.core.boot.BootLoader.

Beskrivelse: De statiske metoder BootLoader.startup(), shutdown() og run() er flyttet til org.eclipse.core.runtime.adaptor.EclipseStarter, der er en del af OSGi-strukturen. Denne API er grænsefladen mellem main() i startup.jar og OSGi-strukturen/Eclipse-runtime. Omstruktureringen af runtime tillod ikke, at disse metoder forblev i BootLoader. Den gamle BootLoader-klasse er nu placeret i runtime-kompatibilitetslaget og er forældet. De flyttede metoder er via stub angivet til ikke at gøre noget.

Der er ingen erstatning for den gamle BootLoader.getRunnable(), fordi runtime ikke længere understøtter anskaffelse af enkeltprogrammer. Brugerne skal i stedet angive det program, de er interesseret i, når de starter platformen.

Påkrævet handling: Generelt bruges denne API af meget få (den kan ikke bruges inde fra en Eclipse-plugin). I de få tilfælde, hvor den bruges, skal koden tilpasses, så den kan bruge de tilsvarende metoder i EclipseStarter.

30. Plugin-eksport omfatter ikke automatisk plugin'ens JAR'er

Hvad påvirkes: Alle plugins.

Beskrivelse: I Eclipse 2.1 behøvede en plugins bin.includes-linje fra build.properties ikke at indeholde listen med JAR'er fra bibliotekserklæringen i filen plugin.xml. Disse JAR'er blev tilføjet gratis. I Eclipse 3.0 er listen med filer i afsnittet bin.includes af build.properties en udtømmende liste, der skal indeholde alle de filer, som plugin-udviklerne mener, skal inkluderes i deres plugins under bygning eller eksport.

Påkrævet handling: Sørg for, at bin.includes-linjen fra filen build.properties inkluderer alle de JAR'er, der er angivet i filen plugin.xml.

31. Eksport af runtime-API igen

Hvad påvirkes: Plugins, som åbner en API, der inkluderer elementer fra et ændret runtime-API.

Beskrivelse: Forskellige plugins åbner en API, som inkluderer elementer fra runtime-API. Med de ændringer til Eclipse 3.0-runtime, som er beskrevet her, skal klient-plugins reevaluere deres brug af runtime-API i deres API.

Påkrævet handling: Dette scenarie forekommer ikke ret tit, fordi kun en ganske lille del af Eclipse-runtime-API ændres. Afhængigt af scenariet kan det være nødvendigt for klienterne at ændre deres API eller fortsat henholde sig til kompatibilitetslaget.

32. Plugin-analysemetoder på platform

Hvad påvirkes: Plugins, som benytter org.eclipse.core.runtime.Platform.parsePlugins(..., Factory).

Beskrivelse: Metoden org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) er flyttet. Den API, der er tilknyttet Factory-argumentet, er flyttet fra plugin'en org.eclipse.core.runtime til plugin'en org.eclipse.core.runtime.compatibility (der er afhængig af runtime-plugin'en). Som følge heraf er analysemetoden også flyttet.

Påkrævet handling: Brugere af denne metode skal bruge samme metode på klassen org.eclipse.core.runtime.model.PluginRegistryModel.

33. Plugin-biblioteket leveret af fragmenter

Hvad påvirkes: Plugins, som angiver kode på deres classpath, men som ikke leverer den kode, dvs. JAR'er leveret af et fragment, f.eks. plugin'en org.eclipse.swt.

Beskrivelse: Den nye runtime skal konvertere plug.xml-filer til manifest.mf-filer i det skjulte. Det sker via en rent mekanisk transformation og en analyse af de JAR'er, der er angivet og leveret af plugin'en. I det tilfælde, hvor en plugin angiver en JAR i plugin'ens classpath, men ikke leverer JAR'en, er der ingen kode at analysere, og plugin-konverteringen kan ikke generere en korrekt manifest.mf.

Påkrævet handling: Udbydere af sådanne plugins skal enten levere den relevante JAR i selve plugin'en, eller de skal vedligeholde/håndlave en META-INF/MANIFEST.MF-fil til deres plugin. Det kan typisk ske vha. en PDE, som bruges til at skaffe den første manifest, og ved derefter at tilføje den relevante Provide-Package-header.

34. Ændringer til byggekommandofiler

Hvad påvirkes: Kommandofiler, f.eks. Ant build.xml-filer, der definerer classpaths, som indeholder runtime-relaterede JAR'er og klassebiblioteker.

Beskrivelse: Den nye runtime indeholder en række nye plugins og JAR'er. Indførelsen af dem blev gjort mulig af refactoring af runtime til stykker, der kunne konfigureres. I de fleste runtime-situationer er disse ændringer usynlige. Hvis du har kommandofiler af typen custom build.xml (eller lignende), som aktuelt kompilerer kode op mod org.eclipse.core.runtime, skal du dog opdatere dem, før de fungerer korrekt. En typisk kommandofil indeholder en classpath-indgang i en <javac>-opgave, som henviser til org.eclipse.core.runtime-plugin'en på følgende måde:

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

Runtime-plugin indeholder fortsat meget af den oprindelige runtime-kode. Visse dele af runtime, som udelukkende er der af kompatibilitetsmæssige årsager, indeholdes dog i en kompatibilitets-plugin (org.eclipse.core.runtime.compatibility). Størstedelen af den nye runtime-kode er indeholdt i en plugin-samling (org.eclipse.osgi.*).

Påkrævet handling: Udviklere skal tilføje de indgange nedenfor, som er nødvendige for at undgå kompileringsfejl. Det samlede sæt af JAR'er er angivet nedenfor, men den typiske bruger behøver kun en delmængde på classpath på kompileringstidspunktet. Som sædvanligt er det valgfrit, om du vil inkludere /bin-bibliotekerne. Indgangene vises her i logiske grupperinger efter den plugin, der leverer dem:

Derudover kan du i visse tilfælde skulle bruger følgende jar'er:

Når du opdaterer sådanne kommandofiler, skal du benytte lejligheden til at rydde op i (dvs. fjerne) referencerne til org.eclipse.core.boot. Denne plugin er forældet og indeholder ikke længere nogen kode. Indgangene kan forblive på classpath, men de tjener intet formål og bør fjernes. Du kan fjerne følgende:

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

35. Ændringer in PDE-bygget Ant-opgave

Hvad påvirkes: Kommandofiler, f.eks. Ant-filer af typen build.xml, der bruger opgaven eclipse.buildScript.

Beskrivelse: PDE Build introducerede en ny egenskab i eclipse.buildScriptopgaven for at kunne kontrollere genereringen af plugin-byggekommandofiler. Det blev muliggjort af indførelsen af den nye OSGi-baserede runtime.

Påkrævet handling: Hvis du vil bruge Eclipse 3.0 til at bygge et 2.1-baseret produkt, skal du introducere egenskaben "buildingOSGi" i eclipse.buildScript og sætte egenskaben til falsk (false). Eksempel:

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

36. Ændringer i eclipse.build-Ant-opgave

Hvad påvirkes: Kommandofiler, f.eks. Ant-filer af typen build.xml, der bruger opgaven eclipse.buildScript.

Beskrivelse: PDE Build introducerede en ny egenskab i eclipse.buildScriptopgaven for at kunne kontrollere genereringen af plugin-byggekommandofiler. Det blev muliggjort af indførelsen af den nye OSGi-baserede runtime.

Påkrævet handling: Hvis du vil bruge Eclipse 3.0 til at bygge et 2.1-baseret produkt, skal du introducere egenskaben "buildingOSGi" i eclipse.buildScript og sætte den til falsk (false). Eksempel:

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

37. Ændringer i eclipse.fetch-Ant-opgaven

Hvad påvirkes: Kommandofiler, f.eks. Ant-filer af typen build.xml, der bruger opgaven eclipse.buildScript.

Beskrivelse: PDE Build har ændret den måde, opgaven eclipse.fetch opfører sig på, for at lette bygningen af eclipse i et automatisk byg. Elementstilen understøtter nu kun én indgang ad gangen, og scriptName ignoreres altid.

Påkrævet handling: Hvis du har en liste med indgange i koden "elements" i et eclipse.fetch-kald, skal du sprede dem over flere kald til eclipse.fetch. Hvis du bruger dem til at angive scriptName, skal du bemærke, at den genererede fetch-kommandofil nu altid hedder "fetch_{elementId}". Eksempel:

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

bliver til

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

38. Udskiftning af install.ini

Filen install.ini er ikke længere inkluderet. Den er erstattet af den nye fil config.ini, som er placeret i konfigurationsunderbiblioteket. De produkter, der brugte filen install.ini til at angive en primær funktion, f.eks. til at give oplysninger om branding, skal i stedet foretage ændringer i filen config.ini. Udover det nye filnavn er navnene på nøglerne ændret.

Værdien af nøglen feature.default.id i 2.1 skal angives som værdien for den nye nøgle eclipse.product. Værdien af eclipse.application skal angives til "org.eclipse.ui.ide.workbench".

Endelig var billedet for åbnings-imaget i 2.1 altid splash.bmp i branding-plugin-biblioteket. I 3.0 er åbnings-imagets placering eksplicit angivet af osgi.splashPath-nøglen i filen config.ini.