Foire aux questions - Migration des plug-ins vers Eclipse 3.0

Pourquoi la version 2.1 de l'API Eclipse est-elle incompatible dans certains cas avec la version 3.0 ?

Eclipse 3.0 est une amélioration d'Eclipse 2.1. Dans certains domaines, nous n'avons pas pu faire évoluer Eclipse tout en gardant une compatibilité parfaite. Les quatre sources principales d'incompatibilités sont les suivantes :

Liste des incompatibilités spécifiques

Un plug-in 2.1 peut-il fonctionner dans Eclipse 3.0 ?

Oui, sauf exception. Si un plug-in repose uniquement sur des API d'Eclipse 2.1, il continuera de fonctionner dans la version 3.0. Les quelques exceptions correspondent aux emplacements de l'API où les modifications entre la version 2.1 et la version 3.0 n'ont pas permis de conserver la compatibilité ; si un plug-in utilise l'une de ces modifications, il ne fonctionnera plus.

Mon plug-in 2.1 utilise des classes des packages internes. Fonctionnera-t-il dans Eclipse 3.0 ?

Si un plug-in repose sur des classes internes ou sur un comportement qui n'est pas spécifié dans l'API d'Eclipse 2.1, il n'est pas possible de savoir si le plug-in fonctionnera dans la version 3.0. Vous devrez essayer.

Comment exécuter mon plug-in dans Eclipse 3.0 sans le modifier ?

Installez votre plug-in 2.1 dans le sous-répertoire eclipse/plugins/ d'un produit reposant sur Eclipse 3.0 et redémarrez Eclipse. Eclipse reconnaît qu'il s'agit d'un plug-in 2.1 non converti (grâce à l'en-tête de plugin.xml) et procède aux ajustements nécessaires automatiquement pour remplacer les modifications apportées aux dépendances du plug-in Platform et aux points d'extension Platform renommés.

Faut-il modifier un plug-in 2.1 pour qu'il soit compilé correctement dans Eclipse 3.0 ?

Oui, dans tous les cas. Il existe des différences entre Eclipse 2.1 et Eclipse 3.0 qui requièrent la modification de tous les plug-ins. Pour recompiler un plug-in développé pour 2.1, vous devez le faire migrer vers la version 3.0 pour pouvoir le modifier pour 3.0.

Comment procéder à la migration de mon plug-in vers Eclipse 3.0 ?

Une fois que vous avez chargé (ou importé) votre projet de plug-in dans un espace de travail d'Eclipse 3.0, sélectionnez Outils PDE > Migrer vers 3.0 (dans le menu contextuel du projet) pour convertir le manifeste du plug-in au format 3.0 et adapter automatiquement la liste des plug-ins et des références Platform requis aux points d'extension Platform renommés. Dans la plupart des cas, le code du plug-in est compilé et exécuté correctement. Vous devez ensuite revoir le code du plug-in pour vérifier qu'il ne dépend pas de l'une des modifications d'API incompatibles.

Est-il certain que des erreurs ou des avertissements de compilation surviendront pour un plug-in qui repose sur une API que les modifications ont rendueincompatible ?

Non. Certains domaines qui ne sont pas compatibles ne sont pas signalés par le compilateur Java.

Puis-je ignorer les avertissements figurant dans le code qui résultent de l'utilisation d'une API déconseillée ?

Oui, à court-terme. A chaque fois que cela est possible, les API obsolètes sont déconseillées et non supprimées, et continuent de fonctionner (bien que dans certaines conditions uniquement). Ainsi, bien qu'il ne soit pas essentiel de ne plus se servir des API déconseillées, le fait qu'elles soit considérées comme obsolètes signifie qu'il existe désormais un meilleur moyen d'effectuer la tâche en question. Evitez d'utiliser les plug-ins pour que l'API soit obsolète dès que possible.

Après avoir procédé à la migration de mon plug-in vers Eclipse 3.0, puis-je encore installer et exécuter le plug-in binaire résultant dans Eclipse 2.1 ?

Non. Cette possibilité n'est pas prise en charge et l'opération échouerait car les points d'extension ont été renommés.

Quel est le rôle d'org.eclipse.core.runtime.compatibility ?

En raison du passage dans la version 3.0 à un environnement d'exécution reposant sur OSGi, certaines API de l'environnement d'exécution de base sont devenues obsolètes. A chaque fois que cela était possible, les API obsolètes figurant dans les packages org.eclipse.core.runtime.*, ainsi que l'implémentation qui leur est associée, ont été déplacées du plug-in org.eclipse.core.runtime vers un nouveau plug-in nommé org.eclipse.core.runtime.compatibility. Par défaut, les plug-ins nouvellement créés dépendent d'org.eclipse.core.runtime et ne doivent utiliser que des API d'environnement d'exécution qui ne sont pas déconseillées. Par contre, des plug-ins existants qui ont migré de la version 2.1 dépendent par défaut d'org.eclipse.core.runtime.compatibility et peuvent également utiliser les anciennes API (le plug-in org.eclipse.core.runtime.compatibility réexporte des API d'org.eclipse.core.runtime). Alors que le plug-in org.eclipse.core.runtime.compatibility peut être inclus dans des configurations d'environnement IDE Eclipse, il ne peut pas figurer dans des produits reposant sur des configurations RCP.

Quel est le rôle d'org.eclipse.ui.workbench.compatibility ?

org.eclipse.ui.workbench.compatibility est un fragment de plug-in qui fournit une compatibilité binaire améliorée pour les plug-ins 2.1 exécutés dans un produit reposant sur Eclipse 3.0. Dans la version 3.0, six méthodes qui dépendent explicitement d'IFile ou d'IMarker ont été retirées de l'interface org.eclipse.ui.IWorkbenchPage pour que la distinctionentre le plan de travail de l'espace de travail et les ressources soit claire. Le fragment org.eclipse.ui.workbench.compatibility permet d'ajouter à nouveau ces méthodes de sorte que les plug-ins 2.1 existants puissent s'exécuter sans être modifiés. Toutefois, les plug-ins migrés vers la version 3.0 qui font référence aux méthodes déplacées provoqueront des erreurs de compilation qui peuvent (uniquement) être résolues par l'appel des méthodes de remplacement qui se trouvent désormais dans org.eclipse.ui.ide.IDE.

Les méthodes IWorkbenchPage en question sont openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) et openSystemEditor(IFile).