Les modifications apportées à Eclipse rendent incompatibles les versions 3.1 et 3.2 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 3.1 vers la version 3.2. Ne consultez cette page que si vous rencontrez des difficultés lors de l'exécution d'un plug-in 3.1 sous la version 3.2.
Objets affectés : les clients de l'API IWorkspace
qui présument que les ressources sont stockées dans le système de fichiers local.
Description :
Avant Eclipse 3.2, chaque élément IResource
disposait d'un fichier ou d'un répertoire correspondant dans un système de fichiers accessible par java.io.File
. Dans
Eclipse 3.2, la prise en charge de la création de ressources dont le contenu est stocké dans un système de fichiers de sauvegarde arbitraire a été ajoutée. Les ressources qui utilisent ce support ne peuvent plus être représentées directement en tant que java.io.File.
Action requise : L'ancienne méthode IResource.getLocation() renvoie le chemin d'accès du système de fichiers local d'une ressource. Cette méthode renvoie la valeur null pour les ressources qui ne sont pas stockées dans le système de fichiers local. La plupart des demandeurs de getLocation() ont procédé ainsi pour obtenir une instance de java.io.File, qui ne peut plus être utilisée pour les ressources qui ne sont pas stockées dans le système de fichiers local.
Le nouveau plug-in org.eclipse.core.filesystem fournit une API de système de fichiers générique qui peut être utilisée à la place de java.io.File. Notamment, une instance de org.eclipse.core.filesystem.IFileStore fournit la plupart des mêmes méthodes que celles disponibles sur java.io.File. Le fragment de code suivant obtient une instance de IFileStore pour une ressource donnée :
IResource resource = ...;//une ressource IFileStore store = EFS.getStore(resource.getLocationURI());
Le tableau suivant fournit des méthodes équivalentes sur IFileStore pour les opérations réalisées généralement avec java.io.File :
java.io.File | IFileStore |
---|---|
delete | delete |
getName | getName |
getParent | getParent |
list | childNames |
mkdir | mkdir(EFS.SHALLOW, null) |
mkdirs | mkdir(EFS.NONE, null) |
renameTo | move |
new FileInputStream(file) | openInputStream |
new FileOutputStream(file) | openOutputStream |
Dans l'API IFileStore, la majeure partie des informations sur un fichier sont stockées dans une structure nommée IFileInfo, obtenue en appelant IFileStore.fetchInfo(). Cette conception permet une plus grande optimisation sur le code à l'aide de java.io.File, dans la mesure où de nombreux attributs relatifs à un fichier peuvent souvent être obtenus à l'aide d'un seul appel du système de fichiers. Les informations contenues dans un élément IFileInfo seront périmées si le fichier sous-jacent est modifié. Par conséquent, les instances doivent uniquement y être conservées le temps nécessaire. Ci-dessous figurent des méthodes sur java.io.File qui ont des équivalents sur IFileInfo :
java.io.File | IFileInfo |
---|---|
canWrite | isReadOnly |
exists | exists |
getName | getName |
isDirectory | isDirectory |
isFile | !isDirectory() |
isHidden | isHidden |
lastModified | getLastModified |
length | getLength |
setLastModified | setLastModified |
setReadOnly | setAttribute(EFS.ATTRIBUTE_READ_ONLY, true) |
A titre d'exemple, le code qui appelait précédemment java.io.File.exists() peut maintenant appeler IFileStore.fetchInfo().exists(). Lorsque IFileInfo est modifié, le résultat doit être stocké à nouveau à l'aide de la méthode IFileStore.putInfo. Par exemple, ce fragment active l'attribut en lecture seule sur un fichier
IFileStore store = ...;//un magasin de fichiers IFileInfo info = store.fetchInfo(); boolean readOnly = info.getAttribute(EFS.ATTRIBUTE_READ_ONLY); info.setAttribute(EFS.ATTRIBUTE_READ_ONLY, !readOnly); store.putInfo(info, EFS.SET_ATTRIBUTES, null);
Comme avec la méthode getLocation(), l'emplacement de la description du projet peut ne plus être dans le système de fichiers local. La méthode IProjectDescription.getLocationURI() peut être utilisée pour obtenir l'emplacement d'une ressource dans un système de fichiers arbitraire.
Certains clients doivent absolument disposer d'une représentation locale d'un fichier. Par exemple, ils peuvent lancer un outil natif au niveau de ce fichier ou utiliser des bibliothèques Eclipse qui peuvent uniquement traiter des ressources de système de fichiers (comme java.util.zip.ZipFile). Dans ces cas, vous pouvez demander à une méthode IFileStore de renvoyer une copie locale mise en cache de son contenu :
IFileStore store = ...;//un magasin de fichiers //vérifier qu'il peut directement être représenté en tant que fichier local java.io.File local = store.toLocalFile(EFS.NONE, null); //dans le cas contraire, demander une copie locale mise en cache du fichier if (local == null) local = store.toLocalFile(EFS.CACHE, null);
Vous devez savoir qu'une fois que la copie d'un fichier mise en cache est obtenue, elle ne reste pas synchronisée avec le fichier en cours à partir duquel elle est extraite. Modifier la copie mise en cache n'entraînera pas la modification du fichier sous-jacent.
Les clients qui ne peuvent pas gérer les ressources en dehors du système de fichiers local peuvent encore vouloir adapter leur code de manière à ce qu'il échoue moins sévèrement. Les clients peuvent vérifier si une ressource réside dans le système de fichiers local et l'ignorer le cas échéant, ou alerter l'utilisateur lorsqu'ils rencontrent une ressource qu'ils ne sont pas en mesure de gérer. Pour déterminer si une ressource est stockée dans le système de fichiers local, vous devez rechercher son schéma de système de fichiers. Il peut être obtenu auprès d'une ressource de la manière suivante :
IResource resource = ...;//une ressource URI uri = resource.getLocationURI(); if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) { //le fichier est stocké dans le système de fichiers local } else { //le fichier n'est pas stocké dans le système de fichiers local }
Si vous avez une instance IFileStore à disposition, vous pouvez obtenir le schéma comme suit :
IFileStore store = ...;//un magasin de fichiers store.getFileSystem().getScheme();
Objets affectés : les clients qui appellent MultiPageEditorSite.progressStart()
ou MultiPageEditorSite.progressEnd()
.
Description : Au cours du développement d'Eclipse 3.0, ces méthodes ont été ajoutées dans le cadre de la procédure de support de progression. Avant la version 3.0, la manière dont la progression était traitée a été modifiée. Cette méthode devenait alors inutile. A la suite d'une erreur du programmeur, ces méthodes publiques ont été conservées pour la version 3.0. Ces deux méthodes n'ont jamais servi aucune fonction dans une version d'Eclipse et ont, par conséquent, été supprimées.
Action requise : les clients appelant
MultiPageEditorSite.progressStart()
ou
MultiPageEditorSite.progressEnd()
doivent utiliser
IWorkbenchSiteProgressService
à la place.
Objets affectés : Les clients disposant d'un fichier config.ini personnalisé et qui migrent leur application vers 3.2.
Description : Avant la version 3.2, la valeur classique pour osgi.bundles contenu dans le fichier config.ini était org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
En raison de la restructuration d'exécution, cette valeur doit être mise à jour pour que l'application puisse démarrer.
Action requise :Modifiez la valeur de osgi.bundles pour inclure org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start.
Objets affectés : Les clients déployant des applications RCP et qui ont indiqué une valeur à osgi.bundles.
Description : Avant la version 3.2, la valeur classique pour osgi.bundles contenu dans le fichier jnlp.file était org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
En raison de la restructuration d'exécution, cette valeur doit être mise à jour, sans quoi des exceptions NullPointerException
risquent d'être émises et d'empêcher le démarrage de l'application.
Action requise :Modifiez la valeur de osgi.bundles pour inclure org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start.
Objets affectés : Les clients qui appellent Bundle.start()
.
Description :
Dans Eclipse, un bundle est indiqué comme étant de type démarrage différé à l'aide de l'en-tête Eclipse-LazyStart
(ou de l'en-tête obsolète Eclipse-AutoStart
). Dans Eclipse 3.1, la méthode
org.osgi.framework.Bundle.start()
ne marquait pas les bundles à démarrage différé comme étant démarrés de manière permanente. Etant donné que les bundles à démarrage différé n'ont jamais été marqués comme démarrés de manière permanente, ils ne démarreraient pas automatiquement au démarrage d'Eclipse. Le javadoc de Bundle.start()
indique que la condition suivante doit se produire lorsque la méthode est appelée :
"Enregistrement permanent que ce bundle a démarré. Lorsque la structure redémarre, ce bundle doit automatiquement démarrer."
Dans Eclipse 3.2, la méthode Bundle.start()
a été corrigée pour marquer le bundle comme étant démarré de manière permanente même si ce dernier est de type démarrage différé. Ce correctif était obligatoire pour respecter la spécification OSGi. Ainsi, les appelants de Bundle.start()
forceront le démarrage du bundle lors du redémarrage d'Eclipse.
En règle générale, cette méthode n'est pas souhaitable car elle entraîne l'activation de bundles inutiles chaque fois qu'Eclipse est démarré. Dans certains cas, elle peut entraîner des résultats imprévus, tels que le bogue 134412.
Action requise : Les clients de Bundle.start()
doivent déterminer si leur intention est d'activer de manière permanente le bundle pour chaque redémarrage. Dans le cas contraire, ils doivent trouver une autre manière d'activer le bundle. Dans la plupart des cas, des appels à Bundle.start()
peuvent être évités simplement en permettant l'activation lente du bundle cible lorsque des classes sont chargées à partir de ce dernier. Dans de rares cas, il peut s'avérer nécessaire qu'un bundle à démarrage différé soit activée de manière forcée. Cependant, il n'est pas marqué de manière permanente pour être activé lors du démarrage. Ces types de scénarios doivent utiliser Bundle.loadClass()
pour charger une classe à partir du bundle qui doit être activé au lieu d'appeler Bundle.start()
.
Dans Eclipse 3.0, l'utilisation du trait de soulignement ('_') dans le segment du qualificateur d'un identifiant de version n'était pas pris en charge, ni appliqué. Si un identifiant de version de plug-in contenait un trait de soulignement dans le qualificateur, ce caractère se transformait en trait d'union ('-') lors de l'exportation du plug-in dans le système de fichiers et lors de l'installation du plug-in à partir d'un site de mise à jour.
Dans Eclipse 3.1, les règles des caractères autorisés dans les qualificateurs ont été assouplies pour inclure le caractère de soulignement. Ainsi, lorsqu'un plug-in ne respectant pas cette règle était exporté ou installé, le qualificateur n'était pas modifié par rapport à son état initial.
Cette modification de sous-titre a été involontairement exclue du guide de migration de la version 3.0 à 3.1.
Le scénario suivi (et pour Eclipse 3.2) consiste à assurer la compatibilité avec Eclipse 3.1. Par conséquent, les plug-ins qui utilisent des caractères de soulignement dans les qualificateurs de leur version doivent être informés des modifications précitées lorsqu'ils utilisent des versions de plug-in anciennes (à la fois lors de l'exportation et lorsqu'elles existent sur des sites de mise à jour). Cela signifie, par exemple, que les fournisseurs de plug-in qui disposent d'anciennes versions de leur plug-in sur un site de mise à jour doivent vérifier que le nom affiché dans le système de fichiers correspond au nom du plug-in.