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.
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.
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 |
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.
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é.
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.
org.eclipse.core.runtime.jobs.ILock
.
L'avantage des ILock
par rapport aux verrouillages génériques consiste en ce qu'ils sont transmis automatiquement à l'unité d'exécution de l'interface utilisateur lors d'une opération syncExec
et qu'un support de détection des blocages est intégré à leur implémentation qui consigne puis résout les blocages.Display.asyncExec
), qui est traitée entièrement dans l'unité d'exécution de l'interface utilisateur.java.lang.String
et org.eclipse.core.runtime.IPath
accessibles simultanément par plusieurs unités d'exécution. L'avantage des objets non modifiables consiste en un accès en lecture extrêmement rapide, mais demande un travail supplémentaire au moment de la modification.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.)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.
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.
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
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.
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.
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.
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.
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.
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 :
Modifications apportées à 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);
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 :
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
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.
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.
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.
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.
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.
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.
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é.
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 :
PRE_DELETE
ou PRE_CLOSE
si applicablePRE_AUTO_BUILD
,POST_AUTO_BUILD
,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 :
PRE_DELETE
ou PRE_CLOSE
si applicablePOST_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 :
PRE_BUILD
(PRE_BUILD
est le nouveau nom de PRE_AUTO_BUILD)
,POST_BUILD
(POST_BUILD
est le nouveau nom de POST_AUTO_BUILD)
,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 :
POST_CHANGE
reçoivent une notification d'absolument toutes les modifications de ressource effectuées lors de leur enregistrement. Il peut s'agir des modifications apportées par les constructeurs et par d'autres programmes d'écoute.PRE_AUTO_BUILD
reçoivent une notification pour toutes les modifications de ressource
sauf pour les modifications apportées par des constructeurs ou des programmes d'écoute des modifications de ressource.POST_AUTO_BUILD
reçoivent une notification pour toutes les modifications de ressource
sauf pour les modifications apportées par les programmes d'écoute POST_AUTO_BUILD
.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.
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.
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);
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.
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.
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.
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.
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)
).
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.
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.
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é.
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
.
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.
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
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"/>
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"/>
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" .../>
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.