Restrictions d'accès

L'environnement d'exécution Eclipse 3.1 offre au développeur l'option de contrôler, sur la base de chaque package, la visibilité du code de plug-in pour les plug-ins en aval.

Un package peut être classé de la manière suivante :

  1. Accessible
  2. Interdit
  3. Interne
  4. Interne avec amis

PDE convertit ces règles de visibilité d'exécution en des règles de restriction d'accès au compilateur lors de la compilation. En conséquence, une violation d'une règle de visibilité est indiquée par le compilateur sous forme d'avertissement ou d'erreur, en fonction de la gravité de cette violation.

Avec la disponibilité de cette prise en charge lors de la compilation, on n'est jamais pris par surprise par des erreurs de chargement de classe lors de la compilation et on reste toujours informé du référencement des types internes.

 

Packages accessibles

Les packages accessibles sont visibles de manière inconditionnelle pour les plug-ins en aval.Alors que les packages API entrent clairement dans cette catégorie, il appartient pleinement au développeur de décider quels autres packages exportés par le plug-in doivent recevoir ce niveau de visibilité.

Afin de déclarer un package accessible, vous devez le répertorier dans la section Packages exportés de la phase d'exécution de l'éditeur du manifeste de plug-in et laisser le paramètre de visibilité par défaut tel qu'il est.

Packages accessibles

 

Packages interdits

Vous pouvez masquer un package à partir des plug-ins en aval à tout moment en l'excluant de la liste dans la section Packages exportés sur la page de la phase d'exécution de l'éditeur du manifeste de plug-in.

Des références à des types à partir d'un package interdit se traduisent par des erreurs de chargement de classe lors de la phase d'exécution.

 Pour éviter ce type de situations :

  1. Le compilateur indiquera les références à des packages interdits à l'aide d'une ERREUR.
  2. Les types provenant des packages interdits ne sont PAS disponibles en tant que propositions dans l'assistant de contenu.

Remarques :

  1. Tous les plug-ins dans Eclipse SDK énumèrent tous leurs packages dans la section Packages exportés.C'est pourquoi, aucun des packages dans SDK n'a un accès interdit.
  2. Le niveau de gravité des références interdites est défini sur la page des préférences Java > Compilateur > Erreurs/Avertissements > API déconseillée ou restreinte.

    Il est fortement recommandé de laisser la gravité d'une référence interdite sur ERREUR.

    Préférences interdites

Packages internes

Les packages internes sont des packages qui ne sont pas destinés à être utilisés par des plug-ins en aval. Ces packages sont visibles pour les plug-ins en aval par défaut.

Les packages internes ne sont masqués pour les plug-ins en aval que lorsque Eclipse est lancé dans le mode strict (c'est-à-dire lorsque vous procédez au lancement avec l'argument VM -Dosgi.resolverMode=strict).

Les packages internes doivent être répertoriés dans la section Packages exportés de la page Phase d'exécution de l'éditeur du manifeste de plug-in avec l'option masqué sélectionnée.

Accès déconseillé

Deux mesures permettent de déconseiller l'utilisation des plug-ins en aval pour le référencement des packages internes :

Accès déconseillé

Assistant de contenu déconseillé

Le niveau de gravité concernant les références déconseillées peut être défini sur la page des préférences Java > Compilateur > Erreurs/Avertissements > API déconseillée ou restreinte.

Préférences déconseillées

 

Packages internes avec amis

Il est important pour un plug-in de pouvoir octroyer un accès complet à ses packages internes vers des plug-ins "amis" désignés. Par exemple, le code PDE est fractionné en plusieurs plug-ins et le plug-in org.eclipse.pde.ui doit avoir un accès complet vers les packages internes de org.eclipse.pde.core.

Dans l'exemple ci-dessous, les amis (les plug-ins org.eclipse.pde et org.eclipse.pde.ui) disposent d'un accès complet vers le package org.eclipse.pde.internal.core.bundle à partir du plug-in org.eclipse.pde.core.

Amis

Les amis sont libres de référencer n'importe quel type à partir du package org.eclipse.pde.internal.core.bundle avec le consentement du compilateur.

Si, d'autre part, un autre plug-in référence un type à partir du package org.eclipse.pde.internal.core.bundle, le compilateur indique la référence sous la forme d'une référence déconseillée comme indiqué dans la section précédente.

 

Activation des restrictions d'accès

POur tirer profit de la prise en charge de la restriction d'accès de l'environnement PDE, la seule exigence réside dans le fait que les plug-ins en question doivent contenir un fichier manifeste (manifest.mf) de bundle OSGi. PDE, qui gère le chemin d'accès à la classe du plug-in, s'occupe ensuite du reste.

Si le plug-in ne contient pas un fichier manifest.mf, il est possible d'en créer un de la manière suivante :

  1. Ouvrez le fichier plugin.xml dans l'éditeur de manifeste du plug-in.
  2. Dans la section Contenu du plug-in de la page Présentation, cliquez sur le lien 'créer un fichier manifeste de bundle OSGi'.

convertir en manifest.mf

 

Inspection des règles d'accès

Vous pouvez inspecter les règles de restriction d'accès imposées sur chaque entrée du chemin d'accès à la classe par PDE sur la page de propriétés Chemin de compilation Java de votre projet de plug-in.

Propriétés du chemin de compilation Java