Incompatibilités entre Eclipse 2.1 et 3.0

Les modifications apportées à Eclipse rendent incompatibles les versions 2.1 et 3.0 au niveau des plug-ins. Les entrées ci-dessous décrivent les zones modifiées et mettent à disposition des instructions pour la migration des plug-ins 2.1 vers la version 3.0. Ne consultez cette page que si vous rencontrez des difficultés lors de l'exécution d'un plug-in 2.1 sous la version 3.0.

  1. Version du manifeste des plug-ins
  2. Restructuration des plug-ins de l'interface utilisateur de la plateforme
  3. Restructuration des plug-ins d'exécution de base de la plateforme
  4. Suppression du plug-in Xerces
  5. Eclipse 3.0 est plus compétitif
  6. Ouverture de fichiers de type IFile dans des éditeurs
  7. Marqueur goto d'éditeur
  8. Programme de lancement d'éditeur
  9. Registre d'éditeur
  10. Registre d'aide des marqueurs du plan de travail
  11. Fournisseurs de documents des éditeurs de texte
  12. Editeurs de texte
  13. Support d'annotation en arrière-plan
  14. Vue Console
  15. Programmes d'écoute des points d'arrêt Java
  16. Accès au presse-papiers dans l'unité d'exécution de l'interface utilisateur
  17. Evénements d'entrée de touches
  18. Parcours des onglets des contrôles personnalisés
  19. Ordre des événements de sélection dans la table SWT et arborescence des widgets
  20. Nouveau niveau de sévérité dans les objets de statut
  21. Notifications des modifications de ressources liées à la compilation
  22. Notifications intermédiaires lors des opérations de l'espace de travail
  23. Extensions du gestionnaire de flux d'URL
  24. Ordre de chargement des classes
  25. Domaine de protection des chargeurs de classe non défini
  26. Transtypage de l'objet PluginModel
  27. Implémentation ILibrary incomplète
  28. Hypothèses non valides relatives à la forme des URL
  29. Méthodes BootLoader déplacées/supprimées
  30. L'exportation d'un plug-in n'inclut pas automatiquement les JAR du plug-in
  31. Nouvelle exportation de l'API d'exécution
  32. Méthodes d'analyse des plug-ins sur la plateforme
  33. Bibliothèques de plug-ins mises à disposition par les fragments
  34. Modifications apportées aux scripts de compilation
  35. Modifications apportées à la tâche Ant de compilation PDE
  36. Modifications apportées à la tâche Ant eclipse.build
  37. Modifications de la tâche Ant eclipse.fetch
  38. Remplacement du fichier install.ini

1. Version du manifeste des plug-ins

L'en-tête des fichiers manifeste des plug-ins (et des fragments de plug-in) inclut désormais une ligne qui identifie la version du manifeste de plug-in appropriée. Avant la version 3.0, les plug-ins ne contenaient pas de ligne <?eclipse ...?> ; à présent, ils doivent obligatoirement en comporter une. Cet ajout permet à l'environnement d'exécution d'Eclipse de reconnaître de façon fiable les plug-ins provenant d'une version antérieure à la version 3.0 et qui n'ont pas été adaptés à la version 3.0, de sorte qu'il puisse automatiquement fournir une meilleure compatibilité binaire. Exemple de fichier plugin.xml (les fichiers fragment.xml sont identiques) :

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

Les manifestes de plug-in créés par l'environnement PDE 3.0 prennent automatiquement cette forme. Il est fortement conseillé d'utiliser l'outil de migration des plug-ins de PDE. Il insère automatiquement la ligne indiquée dans le manifeste des plug-ins et des fragments de plug-in 2.1 et effectue la plupart des autres modifications décrites ici.

Si vous ajoutez cette directive à un fichier plugin.xml (manuellement ou à l'aide de PDE), vous devez aussi mettre à jour le fichier pour qu'il répertorie explicitement les plug-ins dont il dépend. Par exemple, avant Eclipse 3.0, les dépendances à org.eclipse.core.runtime et org.eclipse.core.boot étaient implicites. Avec la version 3.0, org.eclipse.core.boot n'est plus requis et les développeurs doivent choisir org.eclipse.core.runtime ou org.eclipse.core.runtime.compatibility (ou aucun) selon leurs besoins.

Remarque : cette incompatibilité n'a pas d'effet sur la façon dont Eclipse 3.0 exécute les plug-ins binaires 2.1.

2. Restructuration des plug-ins de l'interface utilisateur de la plateforme

Le plug-in org.eclipse.ui, qui était jusqu'à présent le plug-in principal de l'interface utilisateur de la plateforme, met désormais uniquement à disposition l'API et les points d'extension pour le plan de travail générique (non spécifiques de l'IDE). Les API et les points d'extension propres à l'IDE et facultatifs ont été placés dans d'autres plug-ins.

Cette modification a deux effets : (1) les points d'extension org.eclipse.ui déplacés ont de nouveaux ID de point d'extension et (2) la liste des plug-ins requis a changé.

Les points d'extension org.eclipse.ui figurant dans le tableau ci-dessous ont été répartis dans divers plug-ins et leurs ID de point d'extension ont changé. Si un plug-in existant ajoute une extension aux points d'extension déplacés, vous devez modifier la référence à l'attribut "point" de l'élément <extension> dans le fichier manifeste du plug-in de sorte qu'il référence les nouveaux ID de point d'extension correspondants. L'outil de migration des plug-ins de PDE effectue ces modifications.

Remarque : cette incompatibilité n'a pas d'effet sur la façon dont Eclipse 3.0 exécute les plug-ins binaires 2.1. L'environnement d'exécution d'Eclipse 3.0 détecte automatiquement les plug-ins dont la version est antérieure à 3.0 (en raison de l'absence de la ligne <?eclipse version="3.0"?> dans le manifeste du plug-in) et effectue les changements à apporter au point d'extension et à la dépendance du plug-in.

Ancien ID de point d'extension

Nouvel ID de point d'extension

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

Le tableau suivant répertorie les packages d'API que le plug-in org.eclipse.ui mettait à disposition et qui font partie aujourd'hui d'autres plug-ins. (Le nom des packages d'API, des classes, des zones et des méthodes n'a pas changé.) Dans certains cas, les packages d'API sont désormais répartis sur plusieurs plug-ins. Etant donné que les classes d'API visibles par un plug-in sont déterminées par la liste des plug-ins requis de ce plug-in, il se peut que ces changements requièrent la modification des éléments "<requires>" dans le manifeste du plug-in existant en vue de l'accès à la classe d'API.

Cette modification n'a d'effet que sur les plug-ins qui dépendent du plug-in org.eclipse.ui (c'est-à-dire qui inclut <import plugin="org.eclipse.ui"/> dans la section <requires> du manifeste du plug-in) ; les autres plug-ins ne sont pas affectés. Si votre plug-in est affecté, il se peut que vous deviez modifier l'élément <import> ou ajouter des éléments <import>, de sorte que toutes vos classes d'API dont a besoin votre plug-in soient accessibles. Il est fortement conseillé que les plug-ins ne mentionnent que les dépendances aux plug-ins qu'ils utilisent réellement. Si vous incluez des dépendances inutiles, les performances d'exécution sont réduites car le chargeur de classe Java doit rechercher les classes dans toutes les dépendances. (L'outil de migration des plug-ins de PDE traite les dépendances et permet de définir un ensemble réduit.)

Package d'API

Plug-in 2.1

Plug-in(s) 3.0 correspondant(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. Restructuration des plug-ins d'exécution de base de la plateforme

L'environnement d'exécution de la plateforme Eclipse 3.0 repose sur OSGi, ce qui requiert la modification de la structure des deux plug-ins de l'environnement d'exécution de la plateforme, org.eclipse.core.runtime et org.eclipse.core.boot.

Un nouveau plug-in org.eclipse.core.runtime.compatibility fournit une implémentation intermédiaire entre la nouvelle et l'ancienne API, et accueille la plupart des API obsolètes qui se trouvaient avant dans org.eclipse.core.runtime et org.eclipse.core.boot. La restructuration n'a pas d'effet sur les points d'extension de l'environnement d'exécution de la plateforme.

Lors de la migration d'un plug-in existant vers la version 3.0, vous devez mettre à jour le manifeste du plug-in afin de refléter la nouvelle structure des plug-ins de l'environnement d'exécution de la plateforme Eclipse. L'outil de migration des manifestes de plug-in de PDE ajoute une dépendance à org.eclipse.core.runtime.compatibility si nécessaire.

De plus, si vous associez la version 3.0 à votre plug-in (en ajoutant <?eclipse version="3.0"?>) et qu'il définit une classe de plug-in, vous devez ajouter explicitement <import plugin="org.eclipse.core.runtime.compatibility"/> au manifeste du plug-in ou vous assurer que la classe de plug-in définit le constructeur par défaut.

Remarque : cette incompatibilité n'a pas d'effet sur la façon dont Eclipse 3.0 exécute les plug-ins binaires 2.1. L'environnement d'exécution d'Eclipse 3.0 détecte automatiquement les plug-ins dont la version est antérieure à 3.0 (en raison de l'absence de la ligne <?eclipse version="3.0"?> dans le manifeste du plug-in) et effectue les changements à apporter à l'environnement d'exécution de la plateforme.

4. Suppression du plug-in Xerces

Le plug-in org.eclipse.xerces n'est plus nécessaire et a été supprimé. Le support d'analyse XML est intégré à J2SE 1.4 et la présence du plug-in Xerces crée des conflits de chargeur de classe. Les packages d'API javax.xml.parsers, org.w3c.dom.* et org.xml.sax.* qui étaient mis à disposition par le plug-in org.eclipse.xerces sont à présent disponibles à partir des bibliothèques J2SE.

Si votre plug-in requiert le plug-in org.eclipse.xerces, vous devez modifier son manifeste en supprimant la dépendance spécifiée. Une fois l'opération effectuée, compilez le code du plug-in et exécutez-le sans apporter d'autre changement.

Il manquera une condition requise à un plug-in binaire 2.1 avec une dépendance mentionnée au plug-in org.eclipse.xerces lors de son exécution dans une configuration standard d'Eclipse 3.0. Par conséquent, le plug-in ne sera pas activé.

5. Eclipse 3.0 est plus compétitif

Avant la version 3.0, Eclipse agissait principalement dans une unité d'exécution unique. La plupart des points d'extension et des méthodes d'API opéraient dans l'unité d'exécution de l'interface utilisateur ou dans une unité d'exécution générée à partir d'une boîte de dialogue de progression qui bloquait l'unité d'exécution de l'interface utilisateur. La majorité des développeurs de plug-in ne se souciaient pas de l'accès simultané par plusieurs unités d'exécution et n'avaient qu'à s'assurer que toutes les activités de l'interface utilisateur aient lieu dans l'unité d'exécution de l'interface utilisateur. En général, dans Eclipse 3.0, les activités sont plus fréquemment simultanées. De nombreuses opérations ont désormais lieu dans une unité d'exécution en arrière-plan, où elles peuvent s'exécuter simultanément avec d'autres unités d'exécution, y compris l'unité d'exécution principale. Tous les plug-ins dont le code s'exécute dans une unité d'exécution en arrière-plan doivent connaître le niveau d'accès simultané par plusieurs unités d'exécution appliqué à leur code.

En plus des plug-ins qui exécutent explicitement des opérations en arrière-plan avec l'API org.eclipse.core.runtime.jobs, plusieurs fonctions d'API de la plateforme et plusieurs points d'extension utilisent les unités d'exécution en arrière-plan. Les plug-ins qui s'ancrent à ces fonctions doivent s'assurer que leur code est accessible simultanément par plusieurs unités d'exécution. Le tableau suivant répertorie les points d'extension et les API qui exécutent tout ou partie de leur code dans une unité d'exécution en arrière-plan dans Eclipse 3.0.

Point d'extension ou classe d'API

Remarques

org.eclipse.core.runtime.IRegistryChangeListener Nouveau dans Eclipse 3.0, s'exécute en arrière-plan
org.eclipse.core.resources.IResourceChangeListener Evénements AUTO_BUILD désormais en arrière-plan
org.eclipse.core.resources.builders (point d'ext.) Compilation automatique désormais en arrière-plan
org.eclipse.core.resources.ISaveParticipant SNAPSHOT désormais en arrière-plan
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (point d'ext.) Nouveau dans Eclipse 3.0, s'exécute en arrière-plan
org.eclipse.ui.decorators (point d'ext.) Déjà en arrière-plan dans Eclipse 2.1
org.eclipse.ui.startup (point d'ext.) Déjà en arrière-plan dans Eclipse 2.1
org.eclipse.team.core.org.eclipse.team.core.repository (point d'ext.) Plusieurs opérations désormais en arrière-plan
org.eclipse.team.ui.synchronizeParticipants (point d'ext.) Nouveau dans Eclipse 3.0, s'exécute en arrière-plan
org.eclipse.debug.core.launchConfigurationTypes (point d'ext.) S'exécute désormais en arrière-plan
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD s'exécute désormais en arrière-plan, POST_RECONCILE s'exécutait déjà en arrière-plan

Différentes stratégies sont disponibles pour rendre le code accessible simultanément par plusieurs unités d'exécution. L'une des solutions, simple, consiste à vous assurer que tous les travaux sont effectués sur l'unité d'exécution de l'interface utilisateur ce qui garantit l'exécution en série. Il s'agit d'une approche courante pour les plug-ins de l'interface utilisateur qui n'effectue pas un traitement intensif du processeur. A ce stade, il faut savoir que le risque de blocage est inhérent dans Display.syncExec. En général, Display.asyncExec est plus sûr car il n'entraîne pas de risque de blocage, mais vous perdez la précision du contrôle sur le code exécuté.

Vous trouverez ci-dessous d'autres techniques permettant de rendre le code accessible par plusieurs unités d'exécution simultanément.

6. Ouverture de fichiers de type IFile dans des éditeurs

Les méthodes ci-dessous ont été supprimées de l'interface org.eclipse.ui.IWorkbenchPage. IWorkbenchPage est déclaré dans le plan de travail générique, mais les méthodes sont propres aux ressources de façon inhérente.

A la place, les clients de ces méthodes IWorkbenchPage.openEditor doivent appeler les méthodes "static public" correspondantes déclarées dans la classe org.eclipse.ui.ide.IDE (dans le plug-in org.eclipse.ui.ide).

Les clients de ces méthodes IWorkbenchPage.openSystemEditor(IFile) doivent convertir le fichier de type IFile en IEditorInput à l'aide d'un nouveau FileEditorInput(IFile) puis appeler la méthode openEditor(IEditorInput,String). En d'autres termes, réécrivez page.openSystemEditor(file) et remplacez-le par page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Remarque : les clients qui utilisent l'ID éditeur IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID doivent transmettre une entrée d'éditeur qui implémente org.eclipse.ui.IPathEditorInput (comme FileEditorInput).

Remarque : cette incompatibilité n'a pas d'effet sur la façon dont Eclipse 3.0 exécute les plug-ins binaires 2.1. Eclipse 3.0 inclut un mécanisme de compatibilité d'exécution binaire qui garantit que les plug-ins binaires 2.1 existants qui utilisent l'une des méthodes supprimées openEditor et openSystemEditor continuent de fonctionner comme dans la version 2.1 malgré les modifications apportées à l'API. (Les méthodes supprimées sont "ajoutées à nouveau" par le fragment org.eclipse.ui.workbench.compatibility.)

7. Marqueur goto d'éditeur

La méthode ci-dessous a été supprimée de l'interface org.eclipse.ui.IEditorPart. IEditorPart est déclaré dans le plan de travail générique, mais la méthode est propre aux ressources de façon inhérente.

Les méthodes correspondantes ont aussi été supprimées des classes dans le package org.eclipse.ui.part qui implémente IEditorPart, notamment EditorPart, MultiEditor, MultiPageEditorPart et MultiPageEditor. 

A la place, les clients qui appellent cette méthode doivent vérifier que la section de l'éditeur implémente org.eclipse.ui.ide.IGotoMarker ou s'y adapte (dans le plug-in org.eclipse.ui.ide) et si tel est le cas, appeler gotoMarker(IMarker). La classe d'IDE dispose d'une méthode pour cette opération : IDE.gotoMarker(editor, marker);

Les clients qui implémentent un éditeur pouvant se positionner lui-même en fonction des informations IMarker doivent implémenter org.eclipse.ui.ide.IGotoMarker ou s'y adapter.

Etant donné que la seule méthode d'IGotoMarker est gotoMarker(IMarker) et qu'elle possède la même signature et les mêmes spécifications que l'ancienne méthode IEditorPart.gotoMarker(IMarker), les implémentations de l'éditeur existantes peuvent être adaptées : il suffit d'inclure IGotoMarker dans la clause implements de la définition de classe.

Un plug-in binaire 2.1 dont le code appelle cette méthode recevra une exception liée à une erreur de liaison des classes lors de son exécution dans une configuration Eclipse 3.0 standard.

8. Programme de lancement d'un éditeur

L'interface de lancement de l'éditeur org.eclipse.ui.IEditorLauncher est implémentée par des plug-ins qui ajoutent des éditeurs externes. La méthode ci-dessous a été supprimée de cette interface. IEditorLauncher est déclaré dans le plan de travail générique, mais la méthode est propre aux ressources de façon inhérente.

a été remplacée par

A la place, les clients qui appellent IEditorLauncher.open(file) doivent appeler IEditorLauncher.open(file.getLocation()). Les clients qui implémentent cette interface doivent remplacer (ou mettre à niveau) leur implémentation d'open(IFile) par l'une des implémentations d'open(IPath).

Un plug-in binaire 2.1 dont le code appelle cette méthode recevra une exception liée à une erreur de liaison des classes lors de son exécution dans une configuration Eclipse 3.0 standard.

9. Registre d'éditeur

Les méthodes ci-dessous ont été supprimées de l'interface org.eclipse.ui.IEditorRegistry. IEditorRegistry est déclaré dans le plan de travail générique, mais les méthodes sont propres aux ressources de façon inhérente.

Les clients qui appellent getEditors(file) ou getImageDescriptor(file) doivent appeler les méthodes équivalentes "String" : A la place, les clients qui appellent setDefaultEditor(IFile file, String editorId) et getDefaultEditor(IFile file) doivent appeler les méthodes "public static" correspondantes déclarées dans la classe org.eclipse.ui.ide.IDE (dans le plug-in org.eclipse.ui.ide) : Le contrat d'API pour la méthode IEditorRegistrygetDefaultEditor() a également été modifié. Cette méthode, qui est désormais obsolète, renverra toujours le descripteur de l'éditeur externe du système. Cette modification affecte les clients qui partent du principe que l'éditeur par défaut renvoyé est un éditeur de texte.

De nouvelles constantes représentent les identificateurs de l'éditeur externe du système et de l'éditeur en place du système (SYSTEM_EXTERNAL_EDITOR_ID et SYSTEM_INPLACE_EDITOR_ID). Ces deux éditeurs requièrent une entrée d'éditeur qui implémente org.eclipse.ui.IPathEditorInput ou s'y adapte. Le descripteur de l'éditeur en place n'existe pas dans les configurations Eclipse qui ne prennent pas en charge l'éditeur en place.

10. Registre d'aide des marqueurs du plan de travail

La méthode ci-dessous a été supprimée de l'interface org.eclipse.ui.IWorkbench. IWorkbench est déclaré dans le plan de travail générique mais la méthode est propre aux ressources de façon inhérente.

A la place, les clients d'IWorkbench.getMarkerHelpRegistry() doivent appeler la méthode "public static" org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (dans le plug-in org.eclipse.ui.ide).

Un plug-in binaire 2.1 dont le code appelle cette méthode recevra une exception lors de son exécution dans une configuration Eclipse 3.0 standard.

11. Fournisseurs de documents des éditeurs de texte

Pour qu'org.eclipse.ui.texteditor.AbstractTextEditor ne dépendent pas d'IFile, org.eclipse.ui.texteditor.AbstractDocumentProvider introduit le concept d'opération de fournisseur de document (DocumentProviderOperation) et d'exécuteur d'opération de fournisseur de document (IRunnableContext). Lors d'une demande de restauration, de sauvegarde ou de synchronisation, AbstractDocumentProvider crée des opérations de fournisseur de document et utilise l'exécuteur d'opération pour les exécuter. Les sous-classes peuvent fournir le contexte d'exécution avec la méthode getOperationRunner. Vous trouverez ci-après le récapitulatif des modifications auxquelles les clients doivent s'adapter.

La sous-classe AbstractDocumentProvider d'org.eclipse.ui.editors.text.StorageDocumentProvider implémente la méthode getOperationRunner qui renvoie toujours la valeur "null". En d'autres termes, les sous-classes de StorageDocumentProvider ne devraient pas être affectées par cette modification.

La sous-classe StorageDocumentProvider d'org.eclipse.ui.editors.text.FileDocumentProvider implémente la méthode getOperationRunner qui renvoie un objet IRunnableContext pour l'exécution de l'objet donné DocumentProviderOperations dans un objet WorkspaceModifyOperation. Les autres modifications apportées à FileDocumentProvider sont les suivantes :

12. Editeurs de texte

Modifications apportées à org.eclipse.ui.texteditor.AbstractTextEditor :

La sous-classe AbstractTextEditor d'org.eclipse.ui.texteditor.StatusTextEditor fournit la méthode prédicat isErrorStatus(IStatus). Les sous-classes peuvent se remplacer pour déterminer si un statut donné doit prendre en compte une erreur ou l'ignorer.

Modifications apportées à org.eclipse.ui.editors.text.AbstractDecoratedTextEditor :

13. Support d'annotation en arrière-plan

Pour l'introduction du support d'annotation en arrière-plan, les modifications ci-dessous ont été apportées à la fonction Annotation.

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

Eclipse 3.0 dispose d'un nouveau support de console générique. La console générique est disponible via le menu Fenêtre > Afficher la vue > De base > Console et est utilisée par la fonction de débogage d'Eclipse et la fonction d'intégration Ant.

L'ID de vue pour la console est passé de org.eclipse.debug.ui.ConsoleView à org.eclipse.ui.console.ConsoleView. Les plug-ins 2.1 qui ouvre la console par le biais d'un programme échoueront car l'ancienne vue n'existe plus.

15. Programmes d'écoute des points d'arrêt

Dans la version 3.0, les types de retour pour les méthodes org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) et installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) sont passés de boolean à int pour que les programmes d'écoute puissent indiquer "qu'ils ne sont pas concernés". Dans les éditions antérieures à la version 3.0, les programmes d'écoute ne pouvaient choisir que de "suspendre" ou de "ne pas suspendre" lorsqu'ils atteignaient un point d'arrêt et d'"installer" ou de "ne pas installer" lorsqu'un point d'arrêt allait être installé. Dans la version 3.0, les programmes d'écoute peuvent également signaler qu'ils "ne sont pas concernés" par les notifications. Cela permet aux clients de ne prendre une décision que lorsqu'ils sont concernés. Pour les notifications relatives aux "accès au point d'arrêt", le point d'arrêt est suspendu si la décision de l'un des programmes d'écoute est "suspendre" ou si tous les programmes d'écoute signalent qu'ils "ne sont pas concernés"; ; le point d'arrêt n'est pas suspendu si au moins l'un des programmes d'écoute choisit de "ne pas suspendre" et si aucun programme d'écoute ne choisit de "suspendre". De même, pour les notifications relatives à l'"installation d'un point d'arrêt", le point d'arrêt est installé si l'un des programmes d'écoute choisit d'installer ou si tous les programmes d'écoute indiquent qu'ils "ne sont pas concernés"; ; il n'est pas installé si au moins un programme d'écoute choisit de "ne pas installer" et si aucun programme d'écoute ne choisit d'"installer". En général, les implémenteurs doivent renvoyer le paramètre DONT_CARE sauf s'ils penchent fortement d'un côté ou de l'autre. Gardez à l'esprit, par exemple, que la décision "suspendre" écrase tout choix de "ne pas installer" de la part d'un autre programme d'écoute.

L'interface IJavaBreakpointListener est implémentée par des clients qui créent les points d'arrêt ou réagissent aux points d'arrêt en code Java. En-dehors de JDT, les clients sont peu nombreux, à l'exception de celui qui a signalé le problème (bogue 37760) que cette modification corrige. Il s'agit d'une modification majeure du code existant qui implémente l'interface IJavaBreakpointListener. Ce code doit être modifié de sorte qu'il renvoie une valeur int appropriée avant sa compilation et son exécution dans la version 3.0.

16. Accès au presse-papiers dans l'unité d'exécution de l'interface utilisateur

Avant la version 3.0, l'exécution des méthodes de la classe SWT org.eclipse.swt.dnd.Clipboard était tacitement autorisée dans les unités d'exécution autres que l'unité d'exécution de l'interface utilisateur. Des défaillances sous GTK en résultaient : le système d'exploitation requérait que toutes les interactions du presse-papiers soient effectuées dans l'unité d'exécution de l'interface utilisateur. Cette mauvaise utilisation n'a pas été décelée plus tôt car de nombreuses applications ne s'exécutent que sur une seule unité d'exécution et sont principalement testées sous Windows. Pour que l'API du presse-papiers soit durable et adaptée à plusieurs plateformes, la spécification et l'implémentation de toutes les méthodes de l'API du presse-papiers ont été modifiées dans la version 3.0 et émettent une exception SWT(ERROR_THREAD_INVALID_ACCESS) lorsqu'elles sont appelées à partir d'une unité d'exécution autre que l'unité d'exécution de l'interface utilisateur. Les services du presse-papiers sont communément mis à disposition automatiquement par les composants Eclipse tels que l'éditeur de texte, qui isolent de nombreux clients de cette modification majeure. Le code existant qui n'utilise pas directement le presse-papiers doit vérifier que les méthodes de l'API sont appelées sur l'unité d'exécution appropriée avec Display.asyncExec ou syncExec lorsqu'il est judicieux de basculer les accès dans l'unité d'exécution de l'interface utilisateur.

17. Evénements d'entrée de touches

Dans la version 3.0, SWT signale les événements d'entrée de touches avant que le travail soit terminé sur le système d'exploitation, beaucoup plus tôt que dans les versions antérieures. Cette modification permet de prendre en charge les liaisons de touches dans Eclipse, ce qui nécessite l'interception des événements de touche avant le traitement d'un caractère par un widget. Les conséquences de cette modification sont visibles pour le code qui traite des événements org.eclipse.swt.SWT.KeyDown de bas niveau directement. Par exemple, lorsqu'un programme d'écoute d'un widget Text reçoit un événement d'entrée de touche, le contenu du widget (getText()) n'inclut pas encore la touche juste entrée (ce qui était le cas dans les versions antérieures à la version 3.0). Pour obtenir le texte complet à partir du widget, y compris la touche sélectionnée, il est conseillé de traiter des événements SWT.Modify ou SWT.Verify de haut niveau plutôt que des événements SWT.KeyDown de bas niveau ; le code qui procède déjà de cette façon n'est pas concerné par la modification.

18. Parcours des onglets des contrôles personnalisés

Avant la version 3.0, lorsque la classe SWT org.eclipse.swt.widgets.Canvas, ou l'une de ses sous-classes (y compris les widgets personnalisés), était mise en évidence, l'entrée de Ctrl+Tab, Maj+Tab, Ctrl+Flèche vers le haut ou Ctrl+Page vers le bas aurait automatiquement déclenché le passage au widget suivant/précédent sans signaler d'événement de touche. Ce comportement n'était pas spécifié et est contraire à la règle selon laquelle les canevas voient toutes les touches entrées. Pour traiter correctement le passage, il est nécessaire d'enregistrer un programme d'écoute de passage. Pour correctement prendre en charge les liaisons de touches Eclipse dans la version 3.0, le comportement par défaut a été modifié de sorte qu'un canevas voie les événements de touche Ctrl+Tab, Maj+Tab, Ctrl+Flèche vers le haut et Ctrl+Flèche vers le bas au lieu de procéder au passage. Si vous utilisez un canevas brut ou définissez la sous-classe d'un canevas, assurez-vous d'enregistrer un programme d'écoute de passage.

19. Ordre des événements de sélection dans la table SWT et arborescence des widgets

Les sélections d'éléments avec la souris dans les classes SWT d'org.eclipse.swt.widgets.Table et Tree génèrent la séquence d'événements MouseDown-Selection-MouseUp de la même façon dans tous les environnements d'exploitation. De même, les sélections effectuées à l'aide du clavier génèrent la séquence d'événements KeyDown-Selection-KeyUp de la même façon dans tous les environnements d'exploitation. Avant la version 3.0, l'ordre des événements n'était pas identique, et Motif et Photon signalaient toujours l'événement de sélection en premier, par exemple Selection-MouseDown-MouseUp ou Selection-KeyDown-KeyUp. Dans la version 3.0, l'ordre des événements sur Motif et Photon a été modifié pour correspondre aux autres. Il est peu probable que le code existant qui fonctionnait correctement sous (Windows, GTK} et {Motif, Photon} soit affecté. Toutefois, nous vous conseillons de vérifier votre code pour vous assurer qu'il ne repose pas sur un ordre d'événements non valide.

20. Nouveau niveau de sécurité dans les objets de statut

org.eclipse.core.runtime.IStatus est associé à une nouvelle constante de sévérité, IStatus.CANCEL, qui permet d'indiquer l'annulation. Les appelants d'IStatus.getSeverity() qui se basent sur l'ensemble des sévérités possibles limitées à IStatus.OK, INFO, WARNING et ERROR sont affectés par cet ajout. Les appelants de getSeverity doivent mettre à jour leur code afin d'inclure la nouvelle sévérité.

21. Notifications des modifications de ressources liées à la compilation

Dans Eclipse 3.0, les compilations automatiques de l'espace de travail ont lieu désormais dans une unité d'exécution en arrière-plan. Le contrat d'API doit être remplacé par org.eclipse.core.resources.IResourceChangeEvent. Le contrat d'IResourceChangeEvent garantissait l'ordre des événements suivant pour toutes les modifications de l'espace de travail :

  1. notification d'événement PRE_DELETE ou PRE_CLOSE si applicable
  2. exécution de l'opération
  3. notification d'événement PRE_AUTO_BUILD,
  4. si la compilation automatique est activée, exécution de la compilation incrémentielle de l'espace de travail,
  5. notification d'événement POST_AUTO_BUILD,
  6. notification d'événement POST_CHANGE

Etant donné que la compilation automatique s'exécute désormais en arrière-plan, il n'existe plus de garantie pour la relation temporelle entre les événements AUTO_BUILD et l'événement POST_CHANGE. Dans Eclipse 3.0, les étapes 3 à 5 de la structure décrite ci-dessus sont supprimées de l'opération. Le résultat est le suivant :

  1. notification d'événement PRE_DELETE ou PRE_CLOSE si applicable
  2. exécution de l'opération
  3. notification d'événement POST_CHANGE

Régulièrement, la plateforme lance une opération de compilation de l'espace de travail en arrière-plan, que la compilation automatique soit activée ou non. L'heure exacte à laquelle a lieu la compilation n'est pas spécifiée. La structure de l'opération de compilation est la suivante :

  1. notification d'événement PRE_BUILD (PRE_BUILD est le nouveau nom de PRE_AUTO_BUILD),
  2. si la compilation automatique est activée, exécution de la compilation incrémentielle de l'espace de travail,
  3. notification d'événement POST_BUILD (POST_BUILD est le nouveau nom de POST_AUTO_BUILD),
  4. notification d'événement POST_CHANGE

Le point de référence des deltas reçus par les programmes d'écoute de la compilation automatique est différent de celui qui provient des programmes d'écoute de l'événement post-change. Les programmes d'écoute de la compilation reçoivent une notification pour toutes les modifications à partir de la fin de la dernière opération de compilation. Les programmes d'écoute de l'événement Post-change reçoivent un delta qui décrit toutes les modifications depuis la dernière notification de l'événement post-change. Cette nouvelle structure conserve trois caractéristiques de programme d'écoute des modifications de ressource, qui existent depuis la version 1.0 d'Eclipse :

Toutefois, cette approche est différente. Avant la version 3.0 d'Eclipse, les programmes d'écoute de compilation automatique étaient toujours appelés avant les programmes d'écoute POST_CHANGE. Ainsi, le delta reçu par les programmes d'écoute de compilation automatique était toujours un sous-ensemble du delta reçu par les programmes d'écoute POST_CHANGE. A présent, cette relation est inversée. Les programmes d'écoute de la compilation automatique reçoivent un delta qui est un sur-ensemble de tous les deltas fournis aux programmes d'écoute POST_CHANGE depuis la fin de la dernière compilation en arrière-plan. Comme avant, les programmes d'écoute de compilation automatique peuvent modifier l'espace de travail et les programmes d'écoute post-change n'y sont pas autorisés.

A la fin d'une opération de modification de l'espace de travail, les programmes d'écoute des événements AUTO_BUILD ne sont plus notifiés. Il est peu probable que le code client qui enregistre les programmes d'écoute des modifications de ressource avec IWorkspace.addResourceChangeListener(IResourceChangeListener) soit affecté par cette modification car les événements AUTO_BUILD n'ont jamais été signalés à ces programmes d'écoute. Cependant, il se peut que les clients qui utilisent IWorkspace.addResourceChangeListener(IResourceChangeListener,int) et spécifient un masque d'événements incluant les événements AUTO_BUILD ne fonctionnent pas en raison de cette modification s'ils essayent de déterminer le moment auquel les programmes d'écoute de compilation automatique s'exécutent ou l'unité d'exécution dans laquelle ils s'exécutent. Par exemple, si un programme d'écoute de compilation automatique met à jour un modèle de domaine en vue de refléter les modifications apportées à l'espace de travail, il se peut que la mise à jour ne soit pas effectuée lors du retour de l'opération de modification de l'espace de travail. Remarque : seul le code au niveau de l'interface utilisateur peut être affecté de cette façon. Le code au niveau du noyau qui est appelé via une API peut être appelé dans le contexte d'un objet IWorkspaceRunnable ; ainsi, il ne peut jamais savoir avec certitude à quel moment les programmes d'écoute de modifications de ressource seront appelés. Pour remédier au problème, nous vous suggérons d'utiliser POST_CHANGE à la place des programmes d'écoute de compilation pour qu'une notification soit envoyée avant la fin de l'opération.

22. Notifications intermédiaires lors des opérations de l'espace de travail

Toutes les modifications de ressource effectuées lors de la portée dynamique d'un objet IWorkspaceRunnable ne sont plus forcément regroupées dans une seule notification. Vous pouvez encore utiliser ce mécanisme pour regrouper des modifications afin d'éviter des compilations et des notifications inutiles, mais il se peut que la plateforme décide d'effectuer des modifications pendant l'opération. Cette modification du contrat d'API ne représente pas une modification majeure pour les clients existants. Cela revient au même que lorsque la plateforme décide d'appeler IWorkspace.checkpoint régulièrement lors d'une opération à longue durée. Cette modification permet à plusieurs unités d'exécution de modifier l'espace de travail simultanément. Lorsqu'une unité d'exécution a fini de modifier l'espace de travail, une notification est requise pour éviter les problèmes de réactivité, même si une autre opération n'est pas encore terminée. Cette modification permet également aux utilisateurs de commencer à travailler sur un ensemble de ressources avant la fin de l'opération. Par exemple, un utilisateur peut désormais commencer à parcourir les fichiers d'un projet qui est encore en cours de réservation. La nouvelle méthode IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) est associée à un indicateur facultatif, AVOID_UPDATE, dont les opérations peuvent servir d'indices à la plateforme pour déterminer si des mises à jour régulières sont souhaitées.

23. Extensions du gestionnaire de flux d'URL

Objets affectés : les plug-ins qui ajoutent des extensions au point d'extensionorg.eclipse.core.runtime.urlHandlers.

Description : le contrat du point d'extension org.eclipse.core.runtime.urlHandlers a été modifié pour qu'il puisse utiliser le service du gestionnaire de flux d'URL mis à disposition par OSGi. Le support OSGi est meilleur que celui d'Eclipse 2.1 et traite correctement les gestionnaires dynamiques. En raison de divers problèmes de conception avec le mécanisme du gestionnaire d'URL Java de base, les gestionnaires de flux d'URL enregistrés avec le service de gestionnaire d'OSGi doivent implémenter org.osgi.service.url.URLStreamHandlerService.

Action requise : avant, la classe du gestionnaire devait implémenter java.net.URLStreamHandler et étendre le point d'extension urlHandlers. Le point d'extension n'est plus pris en charge et le gestionnaire doit être mis à jour pour l'implémentation de l'interface org.osgi.service.url.URLStreamHandlerService. La structure OSGi fournit une classe de base de type abstract (org.osgi.service.url.AbstractURLStreamHandlerService) qui peut être sous-classée de façon triviale pour remplir ce rôle.

Au lieu d'enregistrer le gestionnaire avec un point d'extension, les plug-ins doivent désormais procéder à l'enregistrement de leur gestionnaire en tant que service. Par exemple,

    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. Ordre de chargement des classes

Objets affectés : les plug-ins qui fournissent les packages mis à disposition qui sont également fournis par d'autres plug-ins. Un nombre très limité de plug-ins sont affectés par cette modification et certains des plug-ins affectés en tireront avantage (voir ci-dessous).

Description : dans Eclipse 2.x, les chargeurs de classe recherchent les classes dans l'ordre suivant : ils consultent (1) le chargeur de classe parent (en pratique, il s'agit du chargeur de classe de démarrage Java), puis (2) leur propre contenu de chemin d'accès aux classes et finalement (3) toutes leurs conditions requises dans l'ordre déclaré. OSGi permet d'optimiser ce modèle. Selon cette approche, un chargeur de classe consulte (1) le chargeur de classe parent (à nouveau, il s'agit du chargeur de classe de démarrage Java) puis (2a) une condition requise unique connue pour l'ajout de classes au package interrogé ou (2b) ses propres entrées de chemin d'accès aux classes pour la classe donnée.

Le chargeur de classe détermine s'il doit consulter ses propres éléments ou ses conditions requises en fonction de ses packages importés et requis. Cette information est déduite du contenu du plug-in dans le cas des plug-ins traditionnels et spécifiée directement dans le cas des plug-ins dont le manifeste de bundles OSGi est explicite. Dans tous les cas, il est possible de savoir a priori quels chargeurs de classe fournissent les classes à quels packages. Les performances sont améliorées et le problème des prérequis multiples ajoutant les mêmes classes est résolu.

Prenons par exemple le cas de Xerces et de Xalan, qui contiennent tous les deux différentes classes provenant du package org.xml. Avec la première approche, le plug-in Xerces verrait sa propre copie des classes alors que le plug-in Xalan verrait la copie de Xerces. Etant donné que ces plug-ins doivent communiquer, une exception ClassCastExceptions survient. Avec la deuxième approche, seul l'un des deux plug-ins ajoute les classes dupliquées et les deux plug-ins voient les mêmes copies.

Action requise : elle dépend des particularités du cas d'usage. Les développeurs concernés doivent revoir leur chemin d'accès aux classes et résoudre les conflits éventuels.

25. Domaine de protection des chargeurs de classe non défini

Objets affectés : les plug-ins dont le domaine de protection du chargeur de classe doit être défini en permanence.

Description : dans Eclipse 2.1, les chargeurs de classe des plug-ins étaient java.security.SecureClassloaders et par conséquent, leur domaine de protection était toujours défini. Dans Eclipse 3.0, les chargeurs de classe n'étendent pas SecureClassloader et ne définissent le domaine de protection que si la sécurité Java est activée (ce qui n'est pas le cas par défaut).

Action requise : elle dépend du scénario dans lequel le plug-in utilise le domaine de protection.

26. Transtypage de l'objet PluginModel

Objets affectés : les plug-ins qui transtypent des objets de type org.eclipse.core.runtime.IPlugin* vers org.eclipse.core.runtime.model.Plugin*Model. Même si la relation entre ces interfaces et les classes de modèle n'est pas spécifiée dans l'API d'Eclipse 2.1, nous avons procédé à cette modification car nous avons trouvé des plug-ins qui reposent sur cette relation dans l'implémentation 2.1.

Description : l'API d'Eclipse fournit une série d'interfaces (comme IPluginDescriptor) et de classes appelées "model" (comme PluginDescriptorModel) liées aux plug-ins ainsi que le registre des plug-ins. Dans l'implémentation d'Eclipse 2.1, il arrive que les classes du modèle implémentent les interfaces pertinentes. Dans le nouveau contexte d'exécution basé sur OSGi, le registre des plug-ins a été considérablement modifié pour distinguer les aspects relatifs aux prérequis et au chargement des classes des plug-ins des aspects relatifs aux extensions et aux points d'extension. Par conséquent, le contexte d'exécution d'Eclipse 3.0 ne peut pas conserver la relation d'implémentation de la version 2.1.

Action requise : le code des plug-ins qui reposent sur cette relation non API doit être modifié selon le cas d'usage. La section relative aux modifications conseillées de ce document ainsi que la documentation Java pour les classes et méthodes liées contiennent plus d'informations à ce sujet.

27. Implémentation ILibrary incomplète

Objets affectés : les plug-ins qui utilisent org.eclipse.core.runtime.ILibrary.

Description : le nouveau contexte d'exécution conserve les entrées du chemin d'accès aux classes dans un formulaire Eclipse différent et incompatible. Par conséquent, la couche de compatibilité ne peut pas modeler correctement les structures OSGi sous-jacentes en tant qu'objets ILibrary. Le support de compatibilité du contexte d'exécution crée des objets ILibrary mais doit décider de valeurs par défaut pour toutes les zones sauf pour le chemin de la bibliothèque.

Action requise : les utilisateurs d'ILibrary peuvent accéder aux valeurs d'en-tête de leur choix (comme Bundle-Classpath) à partir du bundle approprié (voir Bundle.getHeaders()) et utiliser la classe auxiliaire ManifestElement pour interpréter les entrées. Consultez la documentation Java relative aux classes pour plus de détails.

28 Hypothèses non valides relatives à la forme des URL

Objets affectés : les plug-ins qui établissent des hypothèses relatives à leur structure d'installation, à leur emplacement et à l'agencement du système de fichiers local.

Description : les méthodes telles qu'IPluginDescriptor.getInstallURL() renvoient des URL dont la forme est particulière. Bien que leur forme ne soit pas spécifiée, différents plug-ins font des hypothèses en fonction de l'implémentation en cours. Par exemple, ils peuvent attendre une URL de type file: et utiliser URL.getFile(), et utiliser la manipulation java.io.File pour les résultats. Jusqu'à présent, cette approche fonctionnait mais était assez fragile. Par exemple, si un plug-in est installé sur un serveur Web, il se peut qu'une URL http: soit renvoyée. Le nouvel environnement d'exécution d'Eclipse 3.0 est encore plus souple et offre plus de possibilités pour les configurations d'exécution (comme la conservation des plug-ins entiers dans des JAR plutôt que leur répartition dans des répertoires). Ainsi, le nouvel environnement d'exécution reposant sur OSGi n'empêche pas réellement l'API 2.1 de fonctionner, mais pour plusieurs cas, les hypothèses avancées dans les plug-ins sélectionnés ne sont pas valides.

Action requise : les développeurs de plug-in doivent s'assurer que les informations auxquelles ils ont besoin d'accéder sont disponibles via getResource() (et se trouvent dans le chemin d'accès aux classes) ou utiliser l'API appropriée pour accéder au contenu d'un plug-in (comme Bundle.getEntry(String)).

29. Méthodes BootLoader déplacées/supprimées

Objets affectés : le code ne faisant pas partie des plug-ins et qui appelle certaines méthodes de la classe org.eclipse.core.boot.BootLoader.

Description : les méthodes de type "static" BootLoader.startup(), shutdown() et run() ont été déplacées dans org.eclipse.core.runtime.adaptor.EclipseStarter, qui fait partie de la structure OSGi. Cette API est l'interface entre la méthode main() de startup.jar et la structure OSGi/l'environnement d'exécution Eclipse. La restructuration de l'environnement d'exécution n'a pas permis de conserver ces méthodes dans BootLoader. L'ancienne classe BootLoader se trouve désormais dans la couche de compatibilité de l'environnement d'exécution et son utilisation est déconseillée, et les méthodes déplacées n'ont plus de rôle.

L'ancienne méthode BootLoader.getRunnable() n'a pas été remplacée car l'environnement d'exécution ne prend plus en charge l'acquisition d'applications individuelles. A la place, les utilisateurs doivent indiquer l'application qui les intéresse au démarrage de la plateforme.

Action requise : en général, peu de gens utilisent cette API (elle ne peut pas être utilisée à partir d'un plug-in Eclipse). Si tel est le cas, le code doit être adapté pour utiliser les méthodes correspondantes sur EclipseStarter.

30. L'exportation d'un plug-in n'inclut pas automatiquement les JAR du plug-in

Objets affectés : tous les plug-ins.

Description : dans Eclipse 2.1, une ligne bin.includes de plug-in provenant du fichier build.properties ne devait pas contenir la liste des JAR figurant dans la déclaration de bibliothèque du fichier plugin.xml ; ces JAR ont été ajoutés gratuitement. Dans Eclipse 3.0, la liste des fichiers de la section bin.includes du fichier build.properties est exhaustive et doit répertorier tous les fichiers que les développeurs de plug-ins veulent inclure dans leur plug-in lors de la génération ou de l'exportation.

Action requise : vérifiez que la ligne bin.includes du fichier build.properties inclut tous les JAR répertoriés dans votre fichier plugin.xml.

31. Nouvelle exportation de l'API d'exécution

Objets affectés : les plug-ins qui utilisent une API incluant des éléments provenant d'une API d'exécution modifiée.

Description : divers plug-ins utilisent des éléments provenant de l'API d'exécution. Vu les modifications apportées à l'environnement d'exécution d'Eclipse 3.0 et décrites ici, les plug-ins client doivent redéfinir leur utilisation de l'API d'exécution dans leur API.

Action requise : ce scénario est très rare car très peu de modifications ont été apportées à l'API d'exécution Eclipse. Selon le scénario, il se peut que les clients aient à changer leur API ou se fier à la couche de compatibilité.

32. Méthodes d'analyse des plug-ins sur la plateforme

Objets affectés : les plug-ins qui utilisent org.eclipse.core.runtime.Platform.parsePlugins(..., Factory).

Description : la méthode org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) a été déplacée. L'API associée à l'argument Factory a été déplacée du plug-in org.eclipse.core.runtime au plug-in org.eclipse.core.runtime.compatibility (qui dépend du plug-in d'exécution). En conséquence, la méthode d'analyse a été déplacée également.

Action requise : les utilisateurs de cette méthode doivent employer la même méthode sur la classe org.eclipse.core.runtime.model.PluginRegistryModel.

33. Bibliothèques de plug-ins mises à disposition par les fragments

Objets affectés : les plug-ins qui spécifient du code dans le chemin d'accès aux classes mais qui ne le fournissent pas (le JAR est fourni par un fragment ; exemple : le plug-in org.eclipse.swt).

Description : le nouvel environnement d'exécution doit convertir les fichiers plug.xml en fichiers manifest.mf en arrière-plan. Il s'agit d'une transformation mécanique directe et d'une analyse des fichiers Jar répertoriés et fournis par le plug-in. Si un plug-in spécifie un fichier jar dans son chemin d'accès aux classes mais ne fournit pas le fichier Jar, il n'existe pas de code à analyser et le convertisseur de plug-in ne peut pas générer de fichier manifest.mf correct.

Action requise : les fournisseurs de tels plug-ins doivent être modifiés de sorte à fournir le fichier Jar approprié dans le plug-in lui-même ou créer manuellement/conserver un fichier META-INF/MANIFEST.MF pour leur plug-in. En général, PDE est utilisé pour obtenir le fichier manifeste d'origine et pour ajouter l'en-tête Provide-Package appropriée.

34. Modifications apportées aux scripts de compilation

Objets affectés : les scripts (comme les fichiers Ant build.xml) qui définissent les chemins d'accès aux classes contenant des répertoires de classes et de fichiers Jar liés à l'exécution.

Description : le nouvel environnement d'exécution contient plusieurs nouveaux plug-ins et fichiers Jar. Leur ajout a été dicté par la restructuration de l'environnement d'exécution en plusieurs pièces configurables. Dans la plupart des situations d'exécution, ces modifications sont invisibles. Toutefois, si vous disposez de scripts build.xml (ou similaires) personnalisés qui compilent le code avec org.eclipse.core.runtime, vous devez les mettre à jour pour qu'ils fonctionnement correctement. Un script standard contient une entrée de chemin d'accès aux classes dans une tâche <javac> qui référence le plug-in org.eclipse.core.runtime comme indiqué ci-dessous :

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

Le plug-in d'exécution contient toujours une grande partie du code d'exécution d'origine. Toutefois, diverses partie de l'environnement d'exécution qui n'existent que pour la compatibilité se trouvent dans un plug-in de compatibilité (org.eclispe.core.runtime.compatibility). Globalement, le nouveau code d'exécution se trouve dans une série de plug-ins (org.eclipse.osgi.*).

Action requise : les développeurs doivent ajouter les entrées ci-dessous selon leurs besoins pour éviter des erreurs de compilation. La série complète des fichiers Jar mis à disposition est répertoriée ci-dessous, mais les utilisations standard ne requiert qu'un sous-ensemble de fichiers Jar dans le chemin d'accès aux classes lors de la compilation. Comme d'habitude, il vous revient de déterminer l'inclusion des répertoires /bin. Les entrées sont réparties ici en groupes logiques par plug-in :

De plus, il se peut que les fichiers Jar suivants soient requis dans certains cas :

Lorsque vous mettez à jour de tels scripts, profitez-en pour nettoyez (c'est-à-dire supprimer) les références à org.eclipse.core.boot. Ce plug-in est obsolète et ne contient plus de code. Vous pouvez conserver les entrées dans le chemin d'accès aux classes mais elles sont inutiles et il vaut mieux les supprimer. Supprimez :

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

35. Modifications apportées à la tâche Ant de compilation PDE

Objets affectés : les scripts (c'est-à-dire les fichiers build.xml d'Ant) qui utilisent la tâche eclipse.buildScript.

Description : la fonction de compilation PDE a ajouté une nouvelle propriété à la tâche eclipse.buildScript pour le contrôle de la génération des scripts de compilation des plug-ins. Cet ajout a été rendu nécessaire par l'introduction du nouvel environnement d'exécution reposant sur OSGi.

Action requise : pour utiliser Eclipse 3.0 en vue de compiler un produit reposant sur la version 2.1, ajoutez la propriété "buildingOSGi" dans eclipse.buildScript et associez-la à la valeur false. Par exemple :

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

36. Modifications apportées à la tâche Ant eclipse.build

Objets affectés : les scripts (c'est-à-dire les fichiers build.xml d'Ant) qui utilisent la tâche eclipse.buildScript.

Description : la fonction de compilation PDE a ajouté une nouvelle propriété à la tâche eclipse.buildScript pour le contrôle de la génération des scripts de compilation des plug-ins. Cet ajout a été rendu nécessaire par l'introduction du nouvel environnement d'exécution reposant sur OSGi.

Action requise : pour utiliser Eclipse 3.0 en vue de compiler un produit reposant sur la version 2.1, ajoutez la propriété "buildingOSGi" dans eclipse.buildScript et associez-la à la valeur false. Par exemple :

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

37. Modifications apportées à la tâche Ant eclipse.fetch

Objets affectés : les scripts (c'est-à-dire les fichiers build.xml d'Ant) qui utilisent la tâche eclipse.buildScript.

Description : la fonction de compilation PDE a modifié le comportement de la tâche eclipse.fetch en vue de faciliter la compilation d'Eclipse en mode automatique. Le style elements ne prend désormais en charge qu'une entrée à la fois et l'élément scriptName est toujours ignoré.

Action requise : si vous disposiez d'une liste d'entrées dans la balise "elements" d'un appel à eclipse.fetch, répartissez-les entre plusieurs appels à eclipse.fetch. Si vous définissiez l'élément scriptName, sachez que le script d'extraction généré est encore appelé "fetch_{elementId}". Par exemple :

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

becomes

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

38. Remplacement du fichier install.ini

Le fichier install.ini n'est plus inclus. A sa place se trouve le nouveau fichier config.ini dans le sous-répertoire configuration. Pour les produits qui utilisent le fichier install.ini afin de spécifier une fonction principale (c'est-à-dire pour fournir des informations sur le fabricant), modifiez le fichier config.ini à la place. Les noms des clés ont également changé.

La valeur de la clé feature.default.id dans la version 2.1 doit correspondre à la valeur de la nouvelle clé eclipse.product. La valeur d'eclipse.application doit correspondre à "org.eclipse.ui.ide.workbench".

Enfin, dans la version 2.1, l'image d'accueil était toujours splash.bmp et se trouvait dans le répertoire du fabricant. Dans la version 3.0, l'emplacement de l'image d'accueil est indiqué explicitement par la clé osgi.splashPath dans le fichier config.ini.