Incompatibiliteit tussen Eclipse 2.1 en 3.0

Tussen Eclipse 2.1 en 3.0 komen enige punten van incompatibiliteit voor die van invloed op plugins zijn. In de volgende secties worden de gebieden besproken die zijn gewijzigd, en de migratie van 2.1-plugins naar 3.0. U hoeft de informatie alleen te raadplegen als u problemen ondervindt met het uitvoeren van 2.1-plugin in 3.0.

  1. Pluginmanifestversie
  2. Herstructurering van platforminterfaceplugins
  3. Herstructurering van platformkernruntimeplugins
  4. Verwijdering van Xerces-plugin
  5. Eclipse 3.0 is geschikter voor gelijktijdige processen
  6. Editors openen voor IFiles
  7. GotoMarker voor editor
  8. Editors starten
  9. Editorregister
  10. Workbenchmarkerhelpregister
  11. Teksteditordocumentproviders
  12. Teksteditors
  13. Headless-annotatieondersteuning
  14. View Console
  15. Java-onderbrekingspuntlisteners
  16. Klembordtoegang in interfacethread
  17. Events bij ingedrukte toets
  18. Tabtoetsnavigatie voor aangepaste besturingselementen
  19. Selectie-eventvolgorde van widgets in SWT-tabellen en -structuren
  20. Nieuw severityniveau in statusobjecten
  21. Buildgerelateerde meldingen van resourcewijzigingen
  22. Tussentijdse meldingen tijdens werkgebiedbewerkingen
  23. Extensies voor URL-stroomafhandelingsroutines
  24. Laadvolgorde van klassen
  25. Klassenladerbeveiligingsdomein niet ingesteld
  26. Casten van PluginModel-objecten
  27. ILibrary-implementatie niet volledig
  28. Ongeldige aannamen over vorm van URL's
  29. BootLoader-methoden verplaatst/gewist
  30. Bij pluginexport worden de JAR-bestanden van de plugin niet automatisch meegeëxporteerd
  31. Runtime-API's opnieuw exporteren
  32. Pluginontleedmethoden voor platform
  33. Pluginbibliotheken aangeleverd door fragmenten
  34. Wijzigingen in buildscripts
  35. Wijzigingen in Ant-taak PDE-build
  36. Wijzigingen in Ant-taak eclipse.build
  37. Wijzigingen in Ant-taak eclipse.fetch
  38. Vervangen van install.ini

1. Pluginmanifestversie

De header van de manifestbestanden van plugins (en pluginfragmenten) bevat nu een nieuwe regel die de juiste pluginmanifestversie identificeert. Vóór 3.0 bevatten plugins geen regels als <?eclipse ...?>; na 3.0 is zo'n regel verplicht. Door deze wijziging is het mogelijk dat de Eclipse-runtime plugins herkent die ouder zijn dan versie 3.0 en niet zijn gemigreerd naar 3.0. Hierdoor kan de runtime deze plugins automatisch grotere binaire compatibiliteit bieden. Dit is de algemene vorm van het bestand plugin.xml (fragment.xml is vergelijkbaar):

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

Pluginmanifesten die door PDE 3.0 zijn gemaakt, hebben automatisch deze vorm. Het wordt nadrukkelijk aangeraden om de PDE-pluginmigratietool te gebruiken. Deze tool voegt automatisch de aangegeven regel toe in het manifest van 2.1-plugins en pluginfragmenten. Ook is de tool bruikbaar voor andere wijzigingen die hier worden besproken.

Als u de instructie toevoegt aan plugin.xml (handmatig of met PDE), moet het bestand zo worden bijgewerkt dat duidelijk wordt vermeld van welke plugins het afhankelijk is. Vóór Eclipse 3.0 waren bijvoorbeeld dependency's van org.eclipse.core.runtime en org.eclipse.core.boot impliciet. In 3.0 is org.eclipse.core.boot niet meer nodig. Ontwikkelaars moeten org.eclipse.core.runtime of org.eclipse.core.runtime.compatibility kiezen als geschikt (of geen van beide).

Opmerking: Dit is een van de punten van incompatibiliteit die geen invloed heeft op het uitvoeren van een binaire 2.1-plugin in Eclipse 3.0.

2. Herstructurering van platforminterfaceplugins

De org.eclipse.ui-plugin, vroeger de belangrijkste platforminterfaceplugin, biedt nu alleen de API en extensiepunten voor de generieke workbench (d.w.z. niet IDE-specifiek). Optionele en IDE-specifieke API's en extensiepunten zijn verplaatst naar andere plugins.

De gevolgen zijn van tweeërlei aard: (1) de verplaatste org.eclipse.ui-extensiepunten hebben nieuwe extensiepunt-ID's; en (2) de lijst van vereiste plugins is gewijzigd.

De org.eclipse.ui-extensiepunten in de volgende tabel zijn verplaatst naar andere plugins, waardoor de extensiepunt-ID's worden gewijzigd. Als een bestaand plugin en extensie aanlevert aan de verplaatste extensiepunten, moet de verwijzing in het kenmerk "point" van het element <extension> in het manifestbestand worden gewijzigd, zodat het verwijst naar het corresponderende nieuwe extensiepunt-ID. Dit wordt gedaan met de PDE-pluginmigratietool.

Opmerking: Dit is een van de punten van incompatibiliteit die geen invloed heeft op het uitvoeren van een binaire 2.1-plugin in Eclipse 3.0. De Eclipse 3.0-runtime detecteert automatisch plugins van voor versie 3.0 (door afwezigheid van de eerder genoemde regel <?eclipse version="3.0"?> in het pluginmanifest) en compenseert automatisch de wijzigingen van extensiepunt- en plugindependency's.

ID oude extensiepunt

ID nieuwe extensiepunt

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

De volgende tabel bevat de API-pakketten die eerder in de org.eclipse.ui-plugin waren ondergebracht en nu naar verschillende plugins zijn verplaatst. (De namen van de API-pakketten, -klassen, -velden en -methoden zijn niet gewijzigd.) In sommige gevallen zijn de API-pakketten nu verdeeld over meerdere plugins. Omdat de API-klassen die voor alle plugins zichtbaar zijn, worden bepaald aan de hand van de lijst van vereiste plugins voor de plugin, is het misschien nodig om de "<requires>"-elementen in een bestaand pluginmanifest aan te passen zodat er weer toegang is tot de API-klassen.

Deze wijziging is alleen van invloed op plugins die afhankelijk zijn van de org.eclipse.ui-plugin (d.w.z. <import plugin="org.eclipse.ui"/> in de sectie <requires> van het pluginmanifest); de wijziging is niet van invloed op andere plugins. Als uw plugin wel is beïnvloed, is het misschien nodig om het element <import> te wijzigen of om aanvullende <import>-elementen toe te voegen, zodat de API-klassen die uw plugin nodig heeft op elkaar zijn afgestemd. Het wordt nadrukkelijk geadviseerd dat plugins alleen dependency's vermelden van plugins die ze daadwerkelijk gebruiken. Het opnemen van onnodige dependency's vermindert de prestatie van de runtime, omdat de Java-klassenlader de klassen voor alle afhankelijke items moet zoeken. (De PDE-pluginmigratietool past de dependency's aan en helpt bij het vaststellen van de minimale set.)

API-pakket

2.1-plugin

Corresponderende 3.0-plugin(s)

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. Herstructurering van platformkernruntimeplugins

De Eclipse 3.0-platformruntime is gebaseerd op OSGi, waardoor de structuur van twee platformruntimeplugins gewijzigd moet worden: org.eclipse.core.runtime en org.eclipse.core.boot.

Een nieuwe org.eclipse.core.runtime.compatibility-plugin vormt de implementatiebrug tussen de oude en de nieuwe API's. Deze plugin is het nieuwe onderkomen van veel verouderde API's die eerst in org.eclipse.core.runtime en org.eclipse.core.boot waren opgenomen. Platformruntime-extensiepunten worden niet beïnvloed door de herstructurering.

Bij het migreren van de bestaande plugin naar 3.0, moet het pluginmanifest worden bijgewerkt zodat deze aansluit bij de nieuwe structuur van de Eclipse-runtimeplugins. De PDE-manifestmigratietool voegt als het nodig is een dependency toe aan org.eclipse.core.runtime.compatibility.

Let op: als u uw plugin markeert als 3.0 (met <?eclipse version="3.0"?>) en in de plugin een pluginklasse wordt gedefinieerd, moet u expliciet <import plugin="org.eclipse.core.runtime.compatibility"/> in het pluginmanifest opnemen of zorgen dat de standaardconstructor in de klasse Plugin wordt gedefinieerd.

Opmerking: Dit is een van de punten van incompatibiliteit die geen invloed heeft op het uitvoeren van een binaire 2.1-plugin in Eclipse 3.0. De Eclipse 3.0-runtime detecteert automatisch plugins van voor versie 3.0 (door afwezigheid van de regel <?eclipse version="3.0"?> in het pluginmanifest) en compenseert automatisch de wijzigingen van de platformruntime.

4. Verwijdering van Xerces-plugin

De org.eclipse.xerces-plugin is niet meer nodig en is verwijderd. In J2SE 1.4 is XML-ontleedondersteuning ingebouwd en de Xerces-plugin veroorzaakt conflicten bij het laden van klassen. De API-pakketten javax.xml.parsers, org.w3c.dom.* en org.xml.sax.*, die vroeger in de org.eclipse.xerces-plugin waren opgenomen, zijn nu beschikbaar in de J2SE-bibliotheken.

Als de plugin org.eclipse.xerces vereist, moet u deze opgegeven dependency verwijderen uit het pluginmanifest. Als dit is gebeurd, kan de plugincode zonder verdere wijzigingen worden gecompileerd en uitgevoerd.

In een binaire 2.1-plugin met een opgegeven dependency in de org.eclipse.xerces-plugin ontbreekt een vereiste als deze wordt uitgevoerd in een standaard-Eclipse 3.0-configuratie. Als gevolg hiervan wordt de plugin niet geactiveerd.

5. Eclipse 3.0 is geschikter voor gelijktijdige processen

Vóór versie 3.0 werkte Eclipse voornamelijk met een enkelvoudige thread. De meeste API-methoden en extensiepunten werkten in de interfacethread of in een thread die was afgeleid van een voortgangsvenster dat de interfacethread blokkeerde. De meeste pluginschrijvers hoefden zich niet om de veiligheid van een thread te bekommeren. Ze hoefden alleen te zorgen dat alle interfaceactiviteiten in de interfacethread werden afgehandeld. In Eclipse 3.0 worden threads echter veel meer gemeenschappelijk gebruikt. Veel bewerkingen worden nu in een achtergrondthread afgehandeld en kunnen tegelijkertijd met andere threads worden uitgevoerd, inclusief de interfacethread. Alle plugins waarvan de code in een achtergrondthread wordt uitgevoerd, moeten nu zorgen voor beveiliging van de thread.

Naast plugins die expliciet bewerkingen uitvoeren in de achtergrond met de API org.eclipse.core.runtime.jobs, zijn er verschillende platform-API-functies en extensiepunten die gebruik maken van achtergrondthreads. Plugins die een ingang in deze functies hebben, moeten zorgen dat de code in de thread is beveiligd. De volgende tabel bevat een samenvatting van de API's en extensiepunten waarvan de code geheel of gedeeltelijk in een Eclipse 3.0-achtergrondthread wordt verwerkt:

Extensiepunt of API-klasse

Opmerkingen

org.eclipse.core.runtime.IRegistryChangeListener Nieuw in Eclipse 3.0, wordt uitgevoerd op de achtergrond
org.eclipse.core.resources.IResourceChangeListener AUTO_BUILD-events nu op de achtergrond
org.eclipse.core.resources.builders (ext. point) Automatisch bouwen nu op de achtergrond
org.eclipse.core.resources.ISaveParticipant SNAPSHOT nu op de achtergrond
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (ext. point) Nieuw in Eclipse 3.0, wordt uitgevoerd op de achtergrond
org.eclipse.ui.decorators (ext. point) Werd in Eclipse 2.1 al op de achtergrond uitgevoerd
org.eclipse.ui.startup (ext. point) Werd in Eclipse 2.1 al op de achtergrond uitgevoerd
org.eclipse.team.core.org.eclipse.team.core.repository (ext. point) Veel bewerkingen nu op de achtergrond
org.eclipse.team.ui.synchronizeParticipants (ext. point) Nieuw in Eclipse 3.0, wordt uitgevoerd op de achtergrond
org.eclipse.debug.core.launchConfigurationTypes (ext. point) Wordt nu op de achtergrond uitgevoerd
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD wordt nu op de achtergrond uitgevoerd, bij POST_RECONCILE was dat al het geval

Er zijn verschillende strategieën beschikbaar om codethreads te beveiligen. Een interne oplossing is om te zorgen dat al het werk in de interfacethread wordt gedaan, waardoor uitvoering in serie mogelijk is. Dit is een gebruikelijke benadering voor interfaceplugins die geen CPU-intensieve verwerking doen. Let bij deze methode goed op dat Display.syncExec geen vastlopers veroorzaakt. Display.asyncExec is over het algemeen veiliger, omdat er geen kans op vastlopers is. Dit gaat wel ten koste van het nauwkeurige beheer van het moment dat de code wordt uitgevoerd.

Andere technieken om threads te beveiligen zijn onder andere:

6. Editors openen voor IFiles

De volgende methoden zijn verwijderd uit de interface org.eclipse.ui.IWorkbenchPage. IWorkbenchPage wordt gedeclareerd in de generieke workbench, maar de methoden zijn zeer resourcespecifiek.

Clients van deze IWorkbenchPage.openEditor-methoden moeten in plaats hiervan de corresponderende public static-methoden aanroepen die zijn gedeclareerd in de klasse org.eclipse.ui.ide.IDE (in de plugin org.eclipse.ui.ide).

Clients van deze IWorkbenchPage.openSystemEditor(IFile)-methode moeten de IFile converteren naar een IEditorInput met een nieuwe FileEditorInput(IFile) en vervolgens de methode openEditor(IEditorInput,String) aanroepen. Met andere woorden: page.openSystemEditor(file) wordt herschreven als page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Opmerking: clients die het editor-ID IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID gebruiken, moeten een editorinvoer doorgeven die org.eclipse.ui.IPathEditorInput implementeert (wat bij FileEditorInput het geval is).

Opmerking: Dit is een van de punten van incompatibiliteit die geen invloed heeft op het uitvoeren van een binaire 2.1-plugin in Eclipse 3.0. Eclipse 3.0 bevat een mechanisme voor binaire runtimecompatibiliteit dat zorgt dat bestaande binaire 2.1-pluginbestanden die de verwijderde methoden openEditor en openSystemEditor gebruiken, blijven werken zoals ze in 2.1 werkten, ondanks de API-wijziging. (De verwijderde methoden worden in feite "teruggezet" door het fragment org.eclipse.ui.workbench.compatibility.)

7. GotoMarker voor editor

De volgende methode is verwijderd uit de interface org.eclipse.ui.IEditorPart. IEditorPart wordt gedeclareerd in de generieke workbench, maar de methode is zeer resourcespecifiek.

De corresponderende methoden zijn ook verwijderd uit de klassen in het pakket org.eclipse.ui.part die IEditorPart implementeren, te weten EditorPart, MultiEditor, MultiPageEditorPart en MultiPageEditor. 

Clients die deze methode aanroepen, moeten controleren of het editoronderdeel org.eclipse.ui.ide.IGotoMarker implementeert of aanpast (in de plugin org.eclipse.ui.ide). Als dit het geval is moeten ze gotoMarker(IMarker) aanroepen. De IDE-klasse beschikt hiervoor over een handige methode: IDE.gotoMarker(editor, marker);

Clients die een editor implementeren die zichzelf kan positioneren op basis van IMarker-informatie, moeten org.eclipse.ui.ide.IGotoMarker implementeren of aanpassen.

Omdat gotoMarker(IMarker) de enige methode van IGotoMarker is en dezelfde handtekening en specificaties heeft als de oude IEditorPart.gotoMarker(IMarker), kunnen bestaande editorimplementaties zich aan deze wijziging aanpassen door eenvoudig IGotoMarker op te nemen in de implementatieregels van de klassendefinitie.

Als een binaire 2.1-plugin deze methode aanroept, wordt een uitzondering door klassenkoppeling gegenereerd bij uitvoering in de Eclipse 3.0-configuratie.

8. Editors starten

De editorstartinterface org.eclipse.ui.IEditorLauncher wordt geïmplementeerd door plugins die externe editors aanleveren. De volgende methode is verwijderd uit de interface. IEditorLauncher wordt gedeclareerd in de generieke workbench, maar de methode is zeer resourcespecifiek.

De methode is vervangen door

Clients die IEditorLauncher.open(file) aanroepen, moeten in plaats daarvan IEditorLauncher.open(file.getLocation()) aanroepen. Clients die deze interface implementeren, moeten de implementatie van open(IFile) vervangen door open(IPath).

Als een binaire 2.1-plugin deze methode aanroept, wordt een uitzondering door klassenkoppeling gegenereerd bij uitvoering in de Eclipse 3.0-configuratie.

9. Editorregister

De volgende methoden zijn verwijderd uit de interface org.eclipse.ui.IEditorRegistry. IEditorRegistry wordt gedeclareerd in de generieke workbench, maar de methoden zijn zeer resourcespecifiek.

Clients die getEditors(file) of getImageDescriptor(file) aanroepen, moeten de equivalente "String"-methoden aanroepen: Clients die setDefaultEditor(IFile file, String editorId) en getDefaultEditor(IFile file) aanroepen, moeten in plaats hiervan de corresponderende public static-methoden aanroepen die zijn gedeclareerd in de klasse org.eclipse.ui.ide.IDE (in de plugin org.eclipse.ui.ide): Verder is het API-contract voor de methode IEditorRegistrygetDefaultEditor() gewijzigd. Deze methode, die nu gedeprecieerd is, retourneert altijd de editordescriptor System External Editor. Deze wijziging heeft gevolgen voor clients die verwachten dat de standaardeditor een teksteditor is.

Er zijn nieuwe constanten die voor de externe systeemeditor worden gebruikt, en voorgrondeditor-ID's (SYSTEM_EXTERNAL_EDITOR_ID en SYSTEM_INPLACE_EDITOR_ID). Deze twee editors vereisen een editorinvoer die org.eclipse.ui.IPathEditorInput implementeert of aanpast. Let erop dat de voorgrondeditordescriptor niet voorkomt in Eclipse-configuraties die voorgrondbewerking niet ondersteunen.

10. Workbenchmarkerhelpregister

De volgende methode is verwijderd uit de interface org.eclipse.ui.IWorkbench. IWorkbench wordt gedeclareerd in de generieke workbench, maar de methode is zeer resourcespecifiek.

Clients van IWorkbench.getMarkerHelpRegistry() moeten in plaats daarvan de public static-methode org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() aanroepen (in de plugin org.eclipse.ui.ide).

Als een binaire 2.1-plugin deze methode aanroept, wordt een uitzondering gegenereerd bij uitvoering in de Eclipse 3.0-configuratie.

11. Teksteditordocumentproviders

Om org.eclipse.ui.texteditor.AbstractTextEditor onafhankelijk te maken van IFile, biedt org.eclipse.ui.texteditor.AbstractDocumentProvider het concept documentproviderbewerking (DocumentProviderOperation) en een runner voor documentproviderbewerkingen (IRunnableContext). Als AbstractDocumentProvider wordt gevraagd iets opnieuw in te stellen, op te slaan of synchroniseren, worden een documentproviderbewerkingen gemaakt en met een bewerkingsrunner uitgevoerd. De uitvoerbare context kan door subklassen worden aangeleverd via de methode getOperationRunner. Hier volgt een samenvatting van de wijzigingen waaraan clients zich moeten aanpassen:

In de AbstractDocumentProvider-subklasse org.eclipse.ui.editors.text.StorageDocumentProvider wordt de methode getOperationRunner geïmplementeerd, zodat de retourwaarde altijd null is. Dit betekent dat de subklassen van StorageDocumentProvider niet door de wijzigingen worden beïnvloed.

In de StorageDocumentProvider-subklasse org.eclipse.ui.editors.text.FileDocumentProvider wordt de methode getOperationRunner geïmplementeerd. Deze retourneert een IRunnableContext voor het uitvoeren van de betreffende DocumentProviderOperations in een WorkspaceModifyOperation. Andere wijzigingen in FileDocumentProvider zijn:

12. Teksteditors

Wijzigingen in org.eclipse.ui.texteditor.AbstractTextEditor:

De AbstractTextEditor-subklasse org.eclipse.ui.texteditor.StatusTextEditor biedt de predikaatmethode isErrorStatus(IStatus). Subklassen kunnen overschrijvingen uitvoeren om te bepalen welke status als fout beschouwd moet worden.

Wijzigingen in org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:

13. Headless-annotatieondersteuning

Als onderdeel van het invoeren van headless-annotatieondersteuning zijn de volgende wijzigingen in Annotation aangebracht:

        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. View Console

Eclipse 3.0 beschikt over een nieuwe generieke consoleondersteuning. De generieke console is beschikbaar via Venster > View afbeelden > Basis > Console en wordt gebruikt door het Eclipse-foutopsporingsprogramma en Ant-integratie.

Het view-ID van de console is gewijzigd van org.eclipse.debug.ui.ConsoleView in org.eclipse.ui.console.ConsoleView. 2.1-plugins kunnen de console programmatisch openen, omdat de oude view niet meer bestaat.

15. Java-onderbrekingspuntlisteners

In 3.0 zijn de retourtypen voor de methoden org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) en installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) gewijzigd van boolean naar int, zodat listeners "geen voorkeur" kunnen aangeven. In de versie vóór 3.0 hadden listeners alleen de keuze tussen "blokkeren" en "niet blokkeren" bij het bereiken van een onderbrekingspunt en tussen "installeren" en "niet installeren" vlak voor het installeren van een onderbrekingspunt. In 3.0 kunnen listeners in deze gevallen ook "geen voorkeur" kiezen. Hierdoor hoeven clients alleen een beslissing te nemen als de situatie relevant is. Als wordt gemeld dat een "onderbrekingspunt is bereikt", wordt het onderbrekingspunt geblokkeerd als een listener "blokkeren" kiest of als alle listeners "geen voorkeur"; kiezen. Het onderbrekingspunt wordt niet geblokkeerd als minimaal één listener "niet blokkeren" kiest en geen enkele listeners "blokkeren" kiest. Bij "installatiemeldingen van onderbrekingspunten", wordt het onderbrekingspunt geïnstalleerd als een listener installeren kiest of als alle listeners "geen voorkeur"; kiezen. Het onderbrekingspunt wordt niet geïnstalleerd als minimaal één listener "niet installeren" kiest en geen enkele listeners "installeren" kiest. Over het algemeen moeten implementors DONT_CARE retourneren, tenzij ze ergens een duidelijke voorkeur voor hebben. Het is belangrijk om te onthouden dat bij het kiezen van bijvoorbeeld "suspend", de keuze van een andere listener voor "niet blokkeren" wordt overschreven.

De interface IJavaBreakpointListener wordt geïmplementeerd door clients die onderbrekingspunten in Java maken of erop reageren. Er zijn waarschijnlijk weinig clients waarvoor de wijziging een oplossing is, behalve JDT zelf en degene die het probleem heeft gerapporteerd (bug 37760). Het is een belangrijke wijziging voor bestaande code waarin de interfaceIJavaBreakpointListener wordt geïmplementeerd. Deze code moet zo worden gewijzigd dat er een correcte int-waarde wordt geretourneerd voordat de code wordt gecompileerd of uitgevoerd in 3.0.

16. Klembordtoegang in interfacethread

Vóór 3.0 mochten de methoden in de SWT-klasse org.eclipse.swt.dnd.Clipboard impliciet worden uitgevoerd in andere threads dan de interfacethread. Deze fout leidde tot problemen in GTK, waarbij het besturingssysteem vereist dat alle klembordactiviteiten worden uitgevoerd in de interfacethread. De fout is niet eerder ontdekt, omdat veel toepassingen in één thread worden uitgevoerd en vooral onder Windows werden getest. Om de klembord-API te kunnen behouden en geschikt te maken voor alle platforms, zijn in 3.0 de specificaties en implementatie van alle klembord-API-methoden zo gewijzigd dat ze een SWT-uitzondering verwerpen (ERROR_THREAD_INVALID_ACCESS) als ze worden aangeroepen vanuit een andere thread dan de interfacethread. Eclipsecomponenten bieden normaal automatisch klembordservices als de teksteditor, waardoor veel clients met de wijziging te maken krijgen. Bestaande code die niet direct gebruikt maakt van het klembord, moet zorgen dat de API-methoden in de juiste thread worden aangeroepen. Hiertoe wordt Display.asyncExec of syncExec gebruikt voor toegang tot de interfacethread.

17. Events bij ingedrukte toets

In 3.0 rapporteert SWT events die ontstaan door het indrukken van toetsen voordat het werk in het besturingssysteem is gedaan. Dit gebeurt eerder dan in de versies vóór 3.0. De wijziging is doorgevoerd om toetskoppelingen in Eclipse te ondersteunen. Het is hierbij nodig om toetsevents tegen te houden voordat widgets de kans hebben om het teken te verwerken. De gevolgen van de wijziging zijn zichtbaar voor codes die org.eclipse.swt.SWT.KeyDown-events op laag niveau direct afhandelen. Als een listener in een Text-widget bijvoorbeeld een event door een ingedrukte toets ontvangt, bevat de inhoud van de widget (getText()) de zojuist getypte toets nog niet (dit was vóór 3.0 wel het geval). De aanbevolen manier om de volledige tekst uit een widget op te halen, inclusief de huidige sleutel, is om de SWT.Modify- of SWT.Verify-events op hoger niveau af te handelen in plaats van de SWT.KeyDown-event op laag niveau. Codes waarin dit al gebeurt, worden door de wijziging niet beïnvloed.

18. Tabtoetsnavigatie voor aangepaste besturingselementen

Als vóór 3.0 de focus op de SWT-klasse org.eclipse.swt.widgets.Canvas lag of op een van de subklassen (inclusief aangepaste widgets), kon de gebruiker door het typen van Ctrl+Tab, Shift+Tab, Ctrl+PgUp of Ctrl+PgDn automatisch naar de volgende of vorige widget navigeren zonder dat dit een toetsevent genereerde. Dit gedrag was niet gespecificeerd en was in tegenspraak met de regel dat een Canvas-element alle tekens die erin worden ingedrukt, kan zien. De juiste manier om dergelijke navigatie af te handelen, is het registreren van een navigatielistener. Om de juiste toetskoppelingen in Eclipse 3.0 te ondersteunen, is het standaardgedrag gewijzigd. Canvas beschouwt Ctrl+Tab, Shift+Tab, Ctrl+PgUp en Ctrl+PgDn nu als toetsevents in plaats van navigatieopdrachten. Als u een onbewerkt Canvas-element gebruikt of een subklasse van Canvas definieert, moet u zorgen dat er een navigatielistener is geregistreerd.

19. Selectie-eventvolgorde van widgets in SWT-tabellen en -structuren

Het selecteren met de muis van items in de SWT-klassen org.eclipse.swt.widgets.Table en Tree genereert de eventreeks MouseDown-Selection-MouseUp. Deze volgorde geldt voor alle besturingsomgevingen. Toetsenbordevents genereren de eventvolgorde KeyDown-Selection-KeyUp. Ook deze volgorde geldt voor alle besturingsomgevingen. Vóór 3.0 was de eventvolgorde niet uniform. Motif en Photon weken af van de rest door altijd de selectie als eerste te rapporteren, d.w.z. Selection-MouseDown-MouseUp of Selection-KeyDown-KeyUp. In 3.0 is de eventvolgorde van Motif en Photon gewijzigd en sluit nu aan bij de andere. Voor bestaande code die correct werkte onder {Windows, GTK} en in {Motif, Photon} zijn er naar alle waarschijnlijkheid geen gevolgen. Het is echter verstandig om uw code te controleren en te zorgen dat deze niet op een verkeerde eventvolgorde is gebaseerd.

20. Nieuw severityniveau in statusobjecten

org.eclipse.core.runtime.IStatus heeft de nieuwe severityconstante IStatus.CANCEL. Deze kan worden gebruikt om annuleringen aan te geven. Aanroepende items van IStatus.getSeverity() die zijn gebaseerd op de beperkte set severity's IStatus.OK, INFO, WARNING en ERROR, hebben te maken met de gevolgen van deze toevoeging. Aanroepende items van getSeverity moeten zo worden herschreven dat ze de nieuwe severity bevatten.

21. Buildgerelateerde meldingen van resourcewijzigingen

In Eclipse 3.0 worden automatische werkgebiedbuilds in een achtergrondthread uitgevoerd. Hiervoor was een API-contractwijziging nodig in org.eclipse.core.resources.IResourceChangeEvent. Het contract van IResourceChangeEvent garandeerde daarvoor de volgende eventvolgorde voor alle wijzigingen in het werkgebied:

  1. PRE_DELETE- or PRE_CLOSE-eventmelding (als dit van toepassing is)
  2. De bewerking uitvoeren
  3. PRE_AUTO_BUILD-eventmelding
  4. Gewijzigde werkgebiedbuild uitvoeren als Automatisch bouwen is ingeschakeld
  5. POST_AUTO_BUILD-eventmelding
  6. POST_CHANGE-eventmelding

Nu het automatisch bouwen op de achtergrond gebeurt, is er geen garantie meer voor tijdsrelaties tussen AUTO_BUILD-events en POST_CHANGEevents. In Eclipse 3.0 zijn de bovenstaande stappen 3-5 uit de bewerking. Het gevolg ziet er als volgt uit:

  1. PRE_DELETE- or PRE_CLOSE-eventmelding (als dit van toepassing is)
  2. De bewerking uitvoeren
  3. POST_CHANGE-eventmelding

Het platform voert af en toe op de achtergrond een bewerking voor de werkgebiedbuild uit. Het is hierbij niet van belang of Automatisch bouwen is ingeschakeld of niet. De precieze timing van de build wordt niet opgegeven. De structuur van buildbewerkingen ziet er als volgt uit:

  1. PRE_BUILD-eventmelding (PRE_BUILD is de nieuwe naam van PRE_AUTO_BUILD)
  2. Gewijzigde werkgebiedbuild uitvoeren als Automatisch bouwen is ingeschakeld
  3. POST_BUILD-eventmelding (POST_BUILD is de nieuwe naam van POST_AUTO_BUILD)
  4. POST_CHANGE-eventmelding

Het referentiepunt voor de delta's dat door autobuildlisteners wordt ontvangen is niet gelijk aan dat van post-changelisteners. Buildlisteners ontvangen meldingen van alle wijzigingen die na het einde van de vorige build zijn opgetreden. Post-changelisteners ontvangen een delta met een beschrijving van alle wijzigingen die sinds de laatste post-changemelding zijn uitgevoerd. In de nieuwe structuur worden drie kenmerken van resourcewijzigingslisteners gehandhaafd die vanaf Eclipse 1.0 worden gebruikt:

Er zijn in deze benadering echter belangrijke verschillen. Vóór Eclipse 3.0 werden listeners voor automatisch bouwen altijd aangeroepen vóór POST_CHANGE-listeners. Hierdoor was de delta die door autobuildlisteners werd ontvangen, altijd een subset van de delta die door POST_CHANGE-listeners werd ontvangen. Deze relatie is nu in essentie omgekeerd. Autobuildlisteners ontvangen een delta die een superset is van alle delta's die door POST_CHANGE-listeners zijn ontvangen nadat de laatste build op de achtergrond is beëindigd. Autobuildlisteners kunnen net als vroeger het werkgebied wijzigen, terwijl post-changelisteners dit niet kunnen.

Momenteel ontvangen AUTO_BUILD-eventlisteners nog een melding als een werkgebiedwijzigingsbewerking is voltooid. Dit wordt echter afgeschaft. De wijziging is waarschijnlijk niet van invloed op clientcode die resourcewijzigingslisteners registreert met IWorkspace.addResourceChangeListener(IResourceChangeListener), omdat AUTO_BUILD-events niet aan deze listeners werden gerapporteerd. Clients die IWorkspace.addResourceChangeListener(IResourceChangeListener,int) gebruiken en een eventmasker opgeven dat AUTO_BUILD-events bevat, krijgen daarentegen waarschijnlijk met problemen te maken als ze uitgaan van een vastgesteld moment waarop de autobuildlisteners worden uitgevoerd en in welke thread dat gebeurt. Als een autobuildlistener bijvoorbeeld een domeinmodel bijwerkt aan de hand van wijzigingen in het werkgebied, is de update mogelijk niet uitgevoerd als de werkgebiedwijziging een retourwaarde terugstuurt. Het is nuttig om te weten dat alleen code op interfaceniveau op deze manier kan worden beïnvloed. Code op kernniveau die via een API wordt aangeroepen, kan worden aangeroepen in het bereik van een IWorkspaceRunnable, zodat het nooit zeker is wanneer resourcewijzigingslisteners worden aangeroepen. De voorgestelde oplossing van dit probleem is om POST_CHANGE te gebruiken in plaats van buildlisteners als het nodig is meldingen te sturen voordat de bewerking is voltooid.

22. Tussentijdse meldingen tijdens werkgebiedbewerkingen

In het vervolg wordt niet meer gegarandeerd dat alle resourcewijzigingen die zich voordoen in het dynamische bereik van een IWorkspaceRunnable, in een batch met één melding worden verwerkt. Dit mechanisme kan nog steeds worden gebruikt voor wijzigingsbatches om onnodige builds en meldingen te voorkomen, maar het platform kan nu besluiten om meldingen tijdens de bewerking uit te voeren. Deze API-contractwijziging is waarschijnlijk niet van groot belang voor bestaande clients. Het effect is vergelijkbaar met als het platform besluit IWorkspace.checkpoint periodiek aan te roepen tijdens langdurige bewerkingen. De reden voor de wijziging is dat het nu mogelijk is dat meerdere threads het werkgebied tegelijkertijd wijzigen. Als een thread klaar is met het wijzigen van het werkgebied, is een melding vereist om te voorkomen dat er responsproblemen optreden, zelfs als andere bewerkingen nog niet zijn voltooid. Door de wijziging is het ook mogelijk dat gebruikers gaan werken met een set resources voordat de bewerking is voltooid. Een gebruiker kan nu bijvoorbeeld door bestanden bladeren in een project dat nog wordt uitgecheckt. De nieuwe methode IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) heeft een optionele vlag, AVOID_UPDATE, die als hint voor het platform kan worden gebruikt om op te geven of er periodieke updates uitgevoerd moeten worden.

23. Extensies voor URL-stroomafhandelingsroutines

Waar zijn de wijzigingen merkbaar: Plugins die extensies leveren aan het extensiepunt org.eclipse.core.runtime.urlHandlers.

Beschrijving: Het contract voor het extensiepunt org.eclipse.core.runtime.urlHandlers is gewijzigd en gebruikt nu de service URL Stream Handler uit OSGi. De OSGi-ondersteuning is beter dan die in Eclipse 2.1 en handelt dynamische handlers correct af. Vanwege verschillende ontwerpproblemen met de Java-basishandlers voor URL's moet org.osgi.service.url.URLStreamHandlerService zijn geïmplementeerd in URLStreamHandlers die zijn geregistreerd bij de OSGi-handler.

Vereiste actie: Vroeger moest java.net.URLStreamHandler in de handlerklassen zijn geïmplementeerd en moesten ze het extensiepunt urlHandlers uitbreiden. Het extensiepunt wordt niet meer ondersteund en in de handler moet de interface org.osgi.service.url.URLStreamHandlerService worden geïmplementeerd. Het OSGi-framework bevat een abstracte basisklasse (org.osgi.service.url.AbstractURLStreamHandlerService) die voorzien van subklassen deze rol voor zijn rekening kan nemen.

In plaats van het registreren van de handler met een extensiepunt, moeten plugins hun handler als service registreren. Een voorbeeld:

    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. Laadvolgorde van klassen

Waar zijn de wijzigingen merkbaar: Plugins die pakketten aanleveren die ook door andere plugins worden aangeleverd. De wijziging heeft gevolgen voor een beperkt aantal plugins. Sommige van deze plugins hebben er zelfs voordeel van (zie verderop).

Beschrijving: In Eclipse 2.x zoeken klassenladers naar klassen in de volgende volgorde: (1) bovenliggende klassenlader (in de praktijk is dit de Java-opstartklassenlader), (2) de eigen klassenpadinhoud en ten slotte (3) alle vereisten in de gedeclareerde volgorde. OSGi biedt een optimalisatie van dit model. De volgorde van deze benadering is (1) bovenliggende klassenlader (normaal dus de Java-opstartklassenlader) en vervolgens (2a) een enkele vereiste waarvan bekend is dat deze klassen aanlevert in het doorzochte pakket of (2b) de eigen klassenpaditems voor de gewenste klassen.

De klassenlader bepaalt of deze zichzelf of de vereisten doorzoekt op basis van de geïmporteerde en vereiste pakketten. Deze informatie wordt bij traditionele plugins afgeleid van de plugininhoud, maar bij plugins met een expliciet OSGi-bundelmanifest direct opgegeven. In beide gevallen is van tevoren bekend welke klassenladers de klasse voor welke pakketten leveren. Dit biedt prestatievoordelen en een oplossing voor het irritante probleem van meerdere vereisten die dezelfde klassen aanleveren.

Voorbeelden zijn Xerces en Xalan, die beide verschillende klassen uit org.xml-pakketten bevatten. Bij de eerste benadering ziet de Xerces-plugin zijn klassen, terwijl de Xalan-plugin hun kopie ziet. Omdat deze plugins moeten communiceren, treden ClassCastExceptions op. Bij de tweede benadering levert slechts een van de twee plugins de duplicaatklassen aan en zien beide plugins dezelfde kopieën.

Te ondernemen actie: De vereiste actie is afhankelijk van de specifieke omstandigheden. Ontwikkelaars die problemen hebben, moeten het klassenpad controleren en eventuele conflicten oplossen.

25. Klassenladerbeveiligingsdomein niet ingesteld

Waar zijn de wijzigingen merkbaar: Plugins die verwachten dat het beveiligingsdomein van de klassenlader altijd is ingesteld.

Beschrijving: In Eclipse 2.1 waren klassenladers java.security.SecureClassloaders. Hiervoor was het beveiligingsdomein altijd ingeschakeld. In Eclipse 3.0 breiden klassenladers SecureClassloader niet uit en stellen het beveiligingsdomein alleen in als de Java-beveiliging wordt ingeschakeld (meestal niet het geval).

Te ondernemen actie: De vereiste actie is afhankelijk van het scenario waarin de plugin het beveiligingsdomein gebruikt.

26. Casten van PluginModel-objecten

Waar zijn de wijzigingen merkbaar: Plugins die objecten van het type org.eclipse.core.runtime.IPlugin* naar org.eclipse.core.runtime.model.Plugin*Model casten. Hoewel de relatie tussen deze interfaces en de modelklassen niet is opgegeven in de Eclipse 2.1-API, vermelden we deze wijziging expliciet. Er zijn namelijk gevallen bekend van plugins die in de 2.1-implementatie gebruik maken van deze relatie.

Beschrijving: De Eclipse-API biedt een reeks interfaces (b.v. IPluginDescriptor) en zogenaamde "modelklassen" (b.v. PluginDescriptorModel), die zijn gerelateerd aan plugins en het pluginregister. Het komt in de Eclipse 2.1-implementatie voor dat de relevante interfaces in de modelklassen zijn geïmplementeerd. In de nieuwe OSGi-gebaseerde runtime is het pluginregister ingrijpend gewijzigd. Er is nu een scheiding mogelijk tussen de klassenlader- en vereistenaspecten van plugins en de extensie- en extensiepuntaspecten. De Eclipse 3.0-runtime is niet in staat de implementatierelatie die in 2.1 aanwezig is, te onderhouden.

Te ondernemen actie: Plugins die zijn gebaseerd op deze niet-API-relatie moeten worden aangepast. Meer informatie hierover is te vinden in de sectie over aanbevolen wijzigingen van dit document en in de javadoc voor gerelateerde klassen en methoden.

27. ILibrary-implementatie niet volledig

Waar zijn de wijzigingen merkbaar: Plugins die org.eclipse.core.runtime.ILibrary gebruiken.

Beschrijving: De nieuwe runtime beheert de klassenpaditems in een andere en niet-compatibele vorm van Eclipse. Als gevolg hiervan is de compatibiliteitslaag niet in staat om de onderliggende OSGi-structuren correct te modelleren als ILibrary-objecten. De compatibiliteitsondersteuning van de runtime maakt ILibrary-objecten, maar moet overal standaardwaarden voor gebruiken, behalve voor het bibliotheekpad.

Te ondernemen actie: ILibrary-gebruikers moeten toegang tot de gewenste headerwaarden (b.v. Bundle-Classpath) vanuit de juiste bundel programmeren (zie Bundle.getHeaders()) en de helperklasse ManifestElement gebruiken om de items te interpreteren. Zie de Javadoc van de klasse voor meer informatie.

28. Ongeldige aannamen over vorm van URL's

Waar zijn de wijzigingen merkbaar: Plugins die een aanname doen over hun installatiestructuur, locatie en de layout van het lokale bestandssysteem.

Beschrijving: Methoden als IPluginDescriptor.getInstallURL() retourneren URL's met een bepaalde vorm. Hoewel de vorm niet opgegeven is, nemen plugins aan dat er een bepaalde vorm wordt gebruikt op basis van de huidige implementatie. Ze kunnen bijvoorbeeld een file:-URL verwachten en URL.getFile() of java.io.File gebruiken om het resultaat te bewerken. Tot nu toe is dit een werkbare, maar kwetsbare benadering. Als een plugin bijvoorbeeld is geïnstalleerd op een webserver, is het mogelijk dat een http:-URL wordt geretourneerd. De nieuwe Eclipse 3.0-runtime is zelfs nog flexibeler en biedt meer mogelijkheden voor uitvoeringsconfiguraties (b.v. het bewaren van gehele plugins in JAR-bestanden in plaats van verspreid over directory's). Dat wil zeggen dat de nieuwe OSGi-gebaseerde runtime de 2.1-API niet direct onbruikbaar maakt, maar dat er meerdere gevallen zijn waarin de aannamen van de huidige plugin onjuist zijn.

Te ondernemen actie: Pluginschrijvers moeten zorgen dat de informatie waartoe ze toegang willen hebben, beschikbaar is via getResource() (en in het klassenpad staat) of de juiste API gebruiken voor toegang tot een plugin (b.v. Bundle.getEntry(String)).

29. BootLoader-methoden verplaatst/gewist

Waar zijn de wijzigingen merkbaar: Niet-plugincode die bepaalde methoden aanroept uit de klasse org.eclipse.core.boot.BootLoader.

Beschrijving: De statische methoden BootLoader.startup(), shutdown() en run() zijn verplaatst naar org.eclipse.core.runtime.adaptor.EclipseStarter, een onderdeel van het OSGi-framework. Deze API is de interface tussen de main() in startup.jar en de OSGi-framework/Eclipse-runtime. De herstructurering van de runtime liet niet toe dat deze methoden in BootLoader bleven. De oude BootLoader-klasse bevindt zich nu in de compatibiliteitslaag van de runtime en is gedeprecieerd. De verplaatste methoden hebben geen wezenlijke functie meer.

Er is geen vervanging voor de oude BootLoader.getRunnable(), omdat de runtime het ophalen van afzonderlijke toepassingen niet meer ondersteunt. Gebruikers moeten bij het starten van het platform aangeven welke toepassing voor hen van belang is.

Te ondernemen actie: Over het algemeen wordt deze API door weinig mensen gebruikt (hij kan niet worden gebruikt vanuit een Eclipse-plugin). In het zeldzame geval dat dit wel het geval is, moet de code zo worden aangepast dat deze de corresponderende methoden in EclipseStarter gebruikt.

30. Bij pluginexport worden de JAR-bestanden van de plugin niet automatisch meegeëxporteerd

Waar zijn de wijzigingen merkbaar: Alle plugins.

Beschrijving: In Eclipse 2.1 hoefde de regel bin.includes in build.properties niet de lijst met JAR-bestanden uit de bibliotheekdeclaratie in het bestand plugin.xml te bevatten. Deze bestanden werden gratis bijgeleverd. In Eclipse 3.0 staat in de sectie bin.includes van build.properties een uitgebreide lijst. Deze moet alle bestanden bevatten die pluginontwikkelaars willen opnemen bij het bouwen of exporteren van hun plugin.

Te ondernemen actie: Zorg dat de regel bin.includes in het bestand build.properties JARS's bevat die in het bestand plugin.xml zijn vermeld.

31. Runtime-API's opnieuw exporteren

Waar zijn de wijzigingen merkbaar: Plugins die werken met API's die elementen uit gewijzigde runtime-API's bevatten.

Beschrijving: Verschillende plugins werken met API's die elementen uit de runtime-API bevatten. Nu de wijzigingen in de Eclipse 3.0-runtime bekend zijn, moeten clientplugins het gebruik van de runtime-API in hun eigen API opnieuw evalueren.

Te ondernemen actie: Dit scenario komt zelden voor, omdat er niet veel aan de Eclipse-runtime-API wordt veranderd. Afhankelijk van het scenario moeten clients hun API wijzigen of zich blijven baseren op de compatibiliteitslaag.

32. Pluginontleedmethoden voor platform

Waar zijn de wijzigingen merkbaar: Plugins die org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) gebruiken.

Beschrijving: De methode org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) is verplaatst. De API die is gekoppeld aan het Factory-argument is verplaatst van de plugin org.eclipse.core.runtime naar de plugin org.eclipse.core.runtime.compatibility (die afhankelijk is van de runtime-plugin). Als gevolg hiervan is ook de onleedmethode verplaatst.

Te ondernemen actie: Gebruikers van deze methode moeten dezelfde methode gebruiken in de klasse org.eclipse.core.runtime.model.PluginRegistryModel.

33. Pluginbibliotheken aangeleverd door fragmenten

Waar zijn de wijzigingen merkbaar: Plugins die code opgeven in hun klassenpad maar de code niet aanleveren (d.w.z.: het JAR-bestand wordt aangeleverd door een fragment, bijvoorbeeld de plugin org.eclipse.swt).

Beschrijving: De nieuwe runtime moet op de achtergrond plug.xml-bestanden converteren naar manifest.mf-bestanden. Dit gebeurt door een rechtstreekse omzetting en een analyse van de JAR-bestanden die door de plugin zijn vermeld en aangeleverd. Als een plugin een JAR-bestand opgeeft in het klassenpad, maar de JAR niet aanlevert, is er geen code voor de analyse en de pluginconvertor kan manifest.mf niet correct genereren.

Te ondernemen actie: Providers van dergelijke plugins moeten het juiste JAR-bestand aanleveren in de plugin zelf of het bestand META-INF/MANIFEST.MF bijhouden. Dit gebeurt meestal door met de PDE het eerste manifest op te halen en de juiste Provide-Packageheader toe te voegen.

34. Wijzigingen in buildscripts

Waar zijn de wijzigingen merkbaar: Scripts (b.v. Ant-build.xml-bestanden) waarin klassenpaden worden gedefinieerd met daarin runtimegerelateerde JAR-bestanden en klassendirectory's.

Beschrijving: De nieuwe runtime bevat een aantal nieuwe plugins en JAR-archieven. Deze waren nodig door het indelen van de runtime in configureerbare delen. In de meeste runtimesituaties zijn deze wijzigingen duidelijk. Als u echter een aangepast build.xml-scripts hebt (of daarop lijkend) waarvoor de code wordt gecompileerd op basis van org.eclipse.core.runtime, moet u deze bijwerken. Meestal bevat een script een klassenpaditem in een <javac>-taak dat als volgt naar de org.eclipse.core.runtime-plugin verwijst:

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

De runtimeplugin behoudt veel van de oorspronkelijke runtimecode. Verschillende onderdelen van de runtime die er alleen voor de compatibiliteit zijn, zijn echter opgenomen in de compatibiliteitsplugin (org.eclipse.core.runtime.compatibility). Het meeste van de nieuwe runtimecode is opgenomen in een verzameling plugins (org.eclipse.osgi.*).

Te ondernemen actie: Ontwikkelaars moeten de betreffende items hieronder opnemen om compileerfouten te voorkomen. De volledige set beschikbare JAR-bestanden is hieronder te vinden, maar tijdens het compileren is meestal alleen een subset in het klassenpad nodig. Zoals gebruikelijk kunt u naar eigen inzicht de /bin-directory's opnemen. De items worden hier in logische groepen per aanleverende plugin opgesomd:

Verder zijn in speciale gevallen de volgende JAR-bestanden vereist:

U moet tijdens het bijwerken van dergelijke scripts tegelijkertijd verwijzingen naar org.eclipse.core.boot verwijderen. Deze plugin is verouderd en bevat geen code meer. De items mogen in het klassenpad blijven staan, maar ze worden niet meer gebruikt en kunnen beter worden verwijderd. Verwijder mogelijk ook:

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

35. Wijzigingen in Ant-taak PDE-build<

Waar zijn de wijzigingen merkbaar: Scripts (b.v. Ant-build.xml-bestanden) die de taak eclipse.buildScript gebruiken.

Beschrijving: In PDE Build is een nieuwe eigenschap van de taak eclipse.buildScript geïntroduceerd. Deze is bedoeld om plugin-buildscripts te beheren. Deze was nodig door de introductie van de nieuwe, OSGi-gebaseerde runtime.

Te ondernemen actie: Als u wilt dat Eclipse 3.0 een 2.1-gebaseerd product bouwt, introduceert u de eigenschap "buildingOSGi" in eclipse.buildScript en stelt u deze in op false. Bijvoorbeeld:

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

36. Wijzigingen in Ant-taak eclipse.build

Waar zijn de wijzigingen merkbaar: Scripts (b.v. Ant-build.xml-bestanden) die de taak eclipse.buildScript gebruiken.

Beschrijving: In PDE Build is een nieuwe eigenschap van de taak eclipse.buildScript geïntroduceerd. Deze is bedoeld om plugin-buildscripts te beheren. Deze was nodig door de introductie van de nieuwe, OSGi-gebaseerde runtime.

Te ondernemen actie: Als u wilt dat Eclipse 3.0 een 2.1-gebaseerd product bouwt, introduceert u de eigenschap "buildingOSGi" in eclipse.buildScript en stelt u deze in op false. Voorbeeld:

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

37. Wijzigingen in Ant-taak eclipse.fetch

Waar zijn de wijzigingen merkbaar: Scripts (b.v. Ant-build.xml-bestanden) die de taak eclipse.buildScript gebruiken.

Beschrijving: In PDE Build is het gedrag gewijzigd van de taak eclipse.fetch om eenvoudiger in automatische stijl Eclipse-builds te kunnen maken. De elementenstijl ondersteunt nu niet meer dan één item per keer en de scriptnaam wordt altijd genegeerd.

Te ondernemen actie: Als u een lijst met items hebt in de tag "elements" van een eclipse.fetch-aanroep, verdeelt u deze over verschillende aanroepen van eclipse.fetch. Als u gewend bent de scriptnaam op te geven, merkt u dat het nu gegenereerde fetchscript altijd "fetch_{elementId}" heet. Voorbeeld:

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

wordt

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

38. Vervangen van install.ini

Het bestand install.ini is niet meer beschikbaar. Zijn plaats wordt ingenomen door het nieuwe bestand config.ini in de configuratiesubdirectorty. Producten die install.ini gebruikten om een primaire feature op te geven (b.v. voor merkgegevens), moeten in plaats daarvan het bestand config.ini wijzigen. Niet alleen de bestandsnaam, maar ook de namen van de sleutels zijn gewijzigd.

De waarde van feature.default.id in 2.1 moet worden ingesteld als waarde van de nieuwe sleutel eclipse.product. De waarde van eclipse.application moet worden ingesteld op "org.eclipse.ui.ide.workbench".

Ten slotte: in 2.1 was splash.bmp altijd de splashafbeelding in de merkdirectory van de plugin. In 3.0 wordt de locatie van de splashafbeelding expliciet bepaald door de sleutel osgi.splashPath in het bestand config.ini.