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.
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.
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 |
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.
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.
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:
org.eclipse.core.runtime.jobs.ILock
.
Het voordeel van ILock
in vergelijking met andere algemene vergrendelingen is dat deze gegevens automatisch overdraagt aan de interfacethread bij het uitvoeren van een syncExec
en dat er vastloopdetectie in de implementatie is ingebouwd, die vastlopers registreert en oplost. Display.asyncExec
), die geheel in de interfacethread wordt verwerkt. java.lang.String
en org.eclipse.core.runtime.IPath
threadveilig te maken. Het voordeel van onveranderlijke objecten is zeer snelle leestoegang. Er is bij wijzigingen echter meer werk vereist. 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.)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.
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.
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
Als een binaire 2.1-plugin deze methode aanroept, wordt een uitzondering door klassenkoppeling gegenereerd bij uitvoering in de Eclipse 3.0-configuratie.
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.
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.
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.
Als een binaire 2.1-plugin deze methode aanroept, wordt een uitzondering gegenereerd bij uitvoering in de Eclipse 3.0-configuratie.
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:
Wijzigingen in org.eclipse.ui.texteditor.AbstractTextEditor:
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
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:
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
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.
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.
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.
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.
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.
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.
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.
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:
PRE_DELETE
- or PRE_CLOSE
-eventmelding (als dit van toepassing is)PRE_AUTO_BUILD
-eventmeldingPOST_AUTO_BUILD
-eventmeldingPOST_CHANGE
-eventmeldingNu het automatisch bouwen op de achtergrond gebeurt, is er geen garantie meer voor tijdsrelaties tussen AUTO_BUILD
-events en POST_CHANGE
events. In Eclipse 3.0 zijn de bovenstaande stappen 3-5 uit de bewerking. Het gevolg ziet er als volgt uit:
PRE_DELETE
- or PRE_CLOSE
-eventmelding (als dit van toepassing is)POST_CHANGE
-eventmeldingHet 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:
PRE_BUILD
-eventmelding (PRE_BUILD
is de nieuwe naam van PRE_AUTO_BUILD)
POST_BUILD
-eventmelding (POST_BUILD
is de nieuwe naam van POST_AUTO_BUILD)
POST_CHANGE
-eventmeldingHet 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:
POST_CHANGE
-listeners ontvangen meldingen van alle resourcewijzigingen die zijn voorgekomen in de periode dat ze geregistreerd zijn. Dit zijn onder andere wijzigingen die zijn aangebracht door builders en wijzigingen door andere listeners. PRE_AUTO_BUILD
-listeners ontvangen meldingen van alle resourcewijzigingen, behalve wijzigingen door builders en resourcewijzigingslisteners.POST_AUTO_BUILD
-listeners ontvangen meldingen van alle resourcewijzigingen, behalve wijzigingen door andere POST_AUTO_BUILD
-listeners.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.
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.
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);
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.
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.
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.
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.
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)
).
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.
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.
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.
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
.
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.
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
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"/>
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"/>
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" .../>
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.