La présente section décrit les modifications à apporter obligatoirement pour que votre plug-in 3.1 adopte les API et les mécanismes de la version 3.2.
Eclipse 3.2 intègre une nouvelle infrastructure visant à associer des configurations de lancement aux ressources. Cette association permet à la plateforme d'effectuer un filtrage des ressources sur les configurations de lancement. Elle permet également à la plateforme de supprimer le cas échéant les configurations de lancement lorsqu'un projet associé est supprimé. La boîte de dialogue de lancement a été améliorée pour prendre en charge un ensemble de filtres permettant de masquer les configurations associées aux projets fermés et supprimés. Par ailleurs, la boîte de dialogue de lancement assure le filtrage en fonction des jeux de documents sélectionnés dans la fenêtre du plan de travail actif, qui peut aussi être sélectionnée dans la boîte de dialogue de lancement.
Il revient au client de gérer le mappage des ressources des configurations de lancement.
Une API a été ajoutée à ILaunchConfigurationWorkingCopy
pour définir les ressources associées à une configuration et une API a été ajoutée à ILaunchConfiguration
pour extraire les ressources associées à une configuration. Par exemple, les onglets, les raccourcis de lancement et les participants à la restructuration doivent être pris en compte lors de la migration.
Le code qui crée ou modifie les configurations de lancement doit également mettre à jour les mappages de ressources.
Eclipse 3.2 intègre une nouvelle infrastructure destinée à migrer les configurations de lancement afin qu'elles soient compatibles avec les nouveaux outils. Par exemple, dans Eclipse 3.2, une prise en charge a été ajoutée pour effectuer un filtrage des configurations de lancement basé sur les ressources. Les configurations de lancement doivent être mises à niveau pour fournir des mappages de ressources afin d'optimiser cette nouvelle fonction. Les utilisateurs peuvent migrer les configurations de lancement dans leur espace de travail à partir de la page de préférence
Exécution/Débogage > Lancement > Configurations de lancement, en cliquant sur le bouton Migrer.
Un nouvel attribut de délégation de migration a été ajouté au point d'extension launchConfigurationTypes
. Ce dernier indique une classe qui implémente la nouvelle interface ILaunchConfigurationMigrationDelegate
.
Une délégation de migration est chargée d'identifier les candidats à la migration et de les migrer.
Un nouvel attribut facultatif a été ajouté au point d'extension launchModes
pour prendre en charge l'externalisation des libellés d'actions de lancement de menus en cascade. Les clients qui ajoutent des modes de lancement spécifient le libellé à utiliser pour lancer les menus en cascade, tels que "Exécuter en tant que". Le nouvel attribut s'intitule launchAsLabel
. Les libellés correspondants ont été fournis par la plateforme pour exécuter, déboguer et profiler les modes de lancement. Pour ce qui est de la compatibilité amont, lorsque le nouvel attribut n'est pas spécifié pour un mode de lancement, les libellés de menu en cascade sont générés comme précédemment, par le biais de MessageFormat avec "{0} As
".
Voir le bogue associé 105235.
ICU4J est un ensemble de bibliothèques Java qui fournit une prise en charge plus complète pour Unicode, la globalisation et l'internationalisation des logiciels. Pour fournir cette fonctionnalité à la communauté Eclipse, ICU4J a été ajouté à la plate-forme créée pour Eclipse 3.2. Vous la verrez dans la génération sous forme de plug-in nommé com.ibm.icu. La plateforme Eclipse utilisera les API ICU dans Eclipse 3.2.
La migration du code d'application peut s'effectuer de manière incrémentale. L'adoption totale de toutes les fonctions ICU4J n'est donc pas nécessaire pour tirer parti des avantages de l'utilisation de ICU4J. Pour plus d'informations sur la manière de migrer votre code afin d'utiliser ICU4J, voir la page ICU4J sur le site Eclipse wiki.
L'ajout du plug-in ICU4J augmente la taille de 3 Mo. Certaines applications sont susceptibles de ne pas intégrer ICU4J si la taille de l'application a priorité sur l'intégration de la fonction ICU4J. Si tel est le cas, un plug-in de remplacement (com.ibm.icu.base) est disponible sur la page de génération de la plateforme Eclipse. Téléchargez le plug-in, supprimez le plug-in com.ibm.icu et son homologue source du répertoire /plugins, puis supprimez le plug-in de remplacement. Cette opération est nécessaire dans la mesure où la plateforme Eclipse a adopté les API ICU pour 3.2. Par conséquent, le simple fait de supprimer le plug-in ICU entraînerait des erreurs de compilation dans le code de la plateforme. La taille du plug-in de remplacement est d'environ 100 Ko et appelle simplement via l'implémentation du JDK par défaut des classes et des API les plus fréquemment utilisées dans ICU4J. Encore une fois, vous pouvez consulter la page ICU4J sur le site Eclipse wiki, pour plus d'informations sur l'utilisation du plug-in de remplacement ICU.
Pour prendre en charge ICU4J dans JFace, certains ajouts d'API de création étaient nécessaires pour empêcher le référencement des classes ICU dans l'API. Cela s'est traduit par l'ajout des éléments suivants :
org.eclipse.jface.viewers.ViewerComparator
, dont org.eclipse.jface.viewers.ViewerSorter
est désormais une sous-classe.org.eclipse.jface.viewers.StructuredViewer
, pour prendre en charge l'ajout de org.eclipse.jface.viewers.ViewerComparator
.La classe ViewerSorter
possède une méthode publique getCollator()
qui renvoie un java.text.Collator
. Comme cette méthode est une API, elle ne peut pas être modifiée simplement pour utiliser un assembleur ICU. Par ailleurs, les classes ICU ne peuvent pas appartenir à l'API (signatures) étant donné qu'une dépendance de plug-in directe sur ICU empêcherait l'utilisation autonome de JFace (avec SWT). Pour respecter ces contraintes, la classe ViewerComparator
qui utilise un java.util.Comparator
, au lieu d'un assembleur ICU, a été ajoutée. Cela s'explique par le fait que la classe d'assembleur ICU implémente java.util.Comparator
; par conséquent n'importe quel élément StructuredViewer
peut à présent utiliser l'assembleur ICU au lieu de java.text.Collator
. Cependant, JFace n'a pas besoin d'avoir une dépendance sur le plug-in ICU4J.
Les deux nouvelles méthodes ajoutées à StructuredViewer
prennent en charge l'utilisation de l'assembleur ICU pour trier le contenu de l'afficheur via un ViewerComparator
, au lieu d'un ViewerSorter
. Il est conseillé que tous les afficheurs StructuredViewer
utilisent à présent les méthodes get/set pour le programme de tri de l'afficheur (comparateur), au lieu des méthodes getSorter()
et setSorter(ViewerSorter)
.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
Le bundle org.eclipse.equinox.common contient plusieurs nouvelles classes d'API (par exemple, Assert
et ListenerList
) ayant des noms communs. Si votre code comporte une classe du même nom et qui utilise des instructions import * pour importer à la fois la classe locale et les classes de l'environnement d'exécution, vous pouvez recevoir le message d'erreur suivant :
Le type ABC est ambigu
Cette erreur peut se résoudre en organisant les importations et en choisissant la source d'importation appropriée.
Consécutivement au déplacement du code dans les nouveaux plug-ins d'exécution, des scripts personnalisés qui référencent org.eclispe.core.runtime de manière explicite peuvent nécessiter l'ajout d'un ou de plusieurs des plug-ins suivants :