FAQ Pluginmigratie Eclipse 3.0

Waarom is de Eclipse-API door wijzigingen incompatibel geworden tussen versie 2.1 en 3.0?

Eclipse 3.0 is ontwikkeld uit Eclipse 2.1. Er waren weinig gebieden waar we Eclipse konden ontwikkelen met volledige handhaving van de compatibiliteit. De vier belangrijkste redenen van incompatibiliteit zijn:

De lijst met specifieke punten van incompatibiliteit.

Werkt een 2.1-plugin in Eclipse 3.0?

Ja, maar met enige uitzonderingen. Als een plugin alleen Eclipse 2.1-API's verwacht, werkt deze ook in 3.0. De weinige uitzonderingen zijn plaatsen in de API waar de wijzigingen van 2.1 naar 3.0 niet compatibel konden worden uitgevoerd; als een plugin een van deze uitzonderingen gebruikt, werkt de plugin niet.

Mijn 2.1-plugin gebruikt klassen in interne pakketten. Werkt de plugin nog in Eclipse 3.0?

Als een plugin is gebaseerd op gedrag of interne klassen die niet zijn gespecificeerd in de Eclipse 2.1-API, is het onmogelijk om te voorspellen of de plugin in 3.0 werkt. U moet het gewoon proberen.

Hoe voer ik mijn plugin uit in Eclipse 3.0 zonder er iets aan te veranderen?

Installeer de 2.1-plugin in de subdirectory eclipse/plugins/ van een op Eclipse 3.0 gebaseerd product en start Eclipse opnieuw op. Eclipse ziet dat de plugin een niet-geconverteerde 2.1-plugin is (herkend aan de header van plugin.xml) en maakt automatisch aanpassingen om wijzigingen in platformplugindependency's te compenseren.

Moeten 2.1-plugins worden gewijzigd om correct gecompileerd te kunnen worden in Eclipse 3.0?

In alle gevallen: ja. Er zijn bepaalde verschillen tussen Eclipse 2.1 en 3.0 die wijzigingen voor alle plugins vereisen. Als u een plugin hebt geschreven voor 2.1 en deze opnieuw wilt compileren, moet deze naar 3.0 worden gemigreerd voordat hij verder ontwikkeld kan worden voor 3.0.

Hoe migreer ik mijn plugin naar Eclipse 3.0?

Zodra u het pluginproject hebt geladen of geïmporteerd in een Eclipse 3.0-werkgebied, converteert u met PDE Tools > Migreren naar 3.0 (voorgrondmenu van het project) het pluginmanifest naar de 3.0-indeling. De lijst met vereiste platformplugins en verwijzingen naar platformextensies die zijn hernoemd, wordt automatisch aangepast. In de meeste gevallen wordt de plugincode correct gecompileerd en uitgevoerd. U moet de code van de plugin vervolgens evalueren en zorgen dat deze niet afhankelijk is van een van de gebieden met een incompatibele API-wijziging.

Kan ik erop rekenen dat voor een plugin compileerfouten of -waarschuwingen worden afgebeeld als deze is gebaseerd op een API die incompatibel is gewijzigd?

Nee. Er zijn bepaalde incompatibele wijzigingen die niet door het Java-compileerprogramma worden aangegeven.

Kan ik waarschuwingen in de code zonder problemen negeren als deze afkomstig zijn van gedeprecieerde API's?

Ja, op korte termijn. Als het mogelijk is, worden verouderde API's gemarkeerd als gedeprecieerd in plaats van gewist. Ze blijven werken, hoewel dit soms alleen onder bepaalde voorwaarden geldt. Meestal is het dus niet urgent om de gedeprecieerde API te verwijderen. Het betekent alleen dat er nu een betere manier is om dingen aan te pakken. U kunt het gebruik van gedeprecieerde plugins door plugins aanpakken als u er tijd voor hebt.

Als ik mijn plugin naar Eclipse 3.0 migreer, kan ik dan nog steeds de binaire plugin installeren en uitvoeren Eclipse 2.1?

Nee. Dit wordt niet ondersteund en werk waarschijnlijk niet doordat de extensiepunten zijn hernoemd.

Wat is het doel van org.eclipse.core.runtime.compatibility?

Doordat in 3.0 gebruik wordt gemaakt van een OSGi-gebaseerde runtime, zijn bepaalde kernruntime-API's verouderd geworden. Waar het mogelijk is, zijn verouderde API's in org.eclipse.core.runtime.*-pakketten uit de org.eclipse.core.runtime-plugin verplaatst naar een nieuwe org.eclipse.core.runtime.compatibility-plugin. Pas gemaakte plugins zijn standaard afhankelijk van org.eclipse.core.runtime. Ze horen alleen gebruik te maken van niet-gedeprecieerde runtime-API's. Anderzijds zijn bestaande plugins die worden gemigreerd vanuit 2.1, standaard afhankelijk org.eclipse.core.runtime.compatibility. Ze kunnen ook gebruik maken van oude API's (de org.eclipse.core.runtime.compatibility-plugin exporteert API's van org.eclipse.core.runtime opnieuw). Het is waarschijnlijk dat de org.eclipse.core.runtime.compatibility-plugin wordt opgenomen in de Eclipse-IDE-configuraties. Het is daarentegen niet waarschijnlijk dat deze wordt opgenomen in producten die zijn gebaseerd op RCP-configuraties.

Wat is het doel van org.eclipse.ui.workbench.compatibility?

org.eclipse.ui.workbench.compatibility is een pluginfragment dat verbeterde binaire compatibiliteit biedt voor 2.1-plugins die worden uitgevoerd in een op Eclipse 3.0 gebaseerd product. In 3.0 zijn zes methoden met een expliciete afhankelijkheid van IFile of IMarker verplaatst uit de org.eclipse.ui.IWorkbenchPage-interface om de workbench effectief te scheiden van het werkgebied en de resources. Het org.eclipse.ui.workbench.compatibility-fragment zorgt dat deze methoden worden teruggezet, zodat bestaande 2.1-plugins zonder aanpassingen kunnen worden uitgevoerd. Let er echter op dat voor plugins die worden gemigreerd naar 3.0 en die naar de verplaatste methoden verwijzen, compileerfouten worden gemeld die (alleen) verholpen kunnen worden door de vervangende methoden aan te roepen die zich nu bevinden in org.eclipse.ui.ide.IDE.

De betreffende IWorkbenchPage-methoden zijn: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) en openSystemEditor(IFile).