Les chemins de classe dynamiques sont le moyen pour PDE de calculer le chemin de génération pour les projets de plug-in dans Eclipse 3.0.
Q : Que signifie la notion de stabilité du chemin d'accès aux classes ?
R : Cette notion permet de mesurer la variabilité des chemins d'accès aux classes en fonction du choix d'auto-hébergement effectué par un développeur. L'idéal serait que les chemins d'accès aux classes restent inchangés, indépendamment des compléments apportés aux projets source dans l'espace de travail. L'auto-hébergement de projets binaires garantit une bonne stabilité des chemins d'accès aux classes car ces derniers contiennent uniquement des références de projet. L'auto-hébergement de projets externes offre une moins bonne stabilité. Les chemins d'accès aux classes restent stables en ce qui concerne l'emplacement d'installation local des bibliothèques externes mais la liste des plug-in présentés comme des projets source doit rester constante pour tous les membres d'une équipe avant que ces projets puissent être partagés dans un référentiel.
Depuis la version 2.0, l'ajout de version de plug-in à l'emplacement des plug-in dans le système de fichiers a diminué un peu plus la stabilité des chemins d'accès aux classes lors de l'utilisation de plug-in externes.
Q : Si les projets binaires offrent une meilleure stabilité des chemins d'accès aux classes, pourquoi ne pas les utiliser tout le temps ?
R : L'auto-hébergement à l'aide de projets binaires importés est un bon choix tant que le nombre de plug-in importés reste limité (quelques dizaines). Pour des produits plus importants, composés de plusieurs centaines de plug-in, une importation en bloc n'est pas envisageable.
En général, les développeurs de ce type de produit effectuent un auto-hébergement avec quelques projets source, une douzaine de projets binaires directement liés et tout le reste, sous la forme de plug-in externes. D'un point de vue purement théorique, il peut sembler improductif d'importer des dizaines et des dizaines de plug-in externes pour pouvoir générer un petit nombre de projets source.
Q : Pour ma part, je préfère la méthode d'auto-hébergement (projets binaires/plug-in externes). Mon équipe peut-elle l'utiliser à condition que tout ses membres fassent de même ?
R : Les chemins d'accès aux classes statiques (utilisant soit des projets binaires, soit des plug-in externes) figent entièrement la méthode d'auto-hébergement que vous avez choisie et obligent tout le monde à l'utiliser.
Q : Que sont les chemins d'accès aux classes dynamiques ?
R : Les chemins d'accès aux classes dynamiques correspondent à une fonctionnalité PDE dans laquelle une partie du chemin d'accès aux classes d'un projet de plug-in liée aux dépendances du plug-in est calculée de manière dynamique à l'aide de la technologie de conteneur de chemin d'accès aux classes JDT. Les chemins d'accès aux classes dynamiques sont résolus 'en temps réel' et sont toujours conformes aux conditions en vigueur dans l'espace de travail.
Etant donné que les chemins d'accès aux classes sont résolus de manière dynamique, les modifications sont prises en compte dans PDE et ces derniers sont toujours à jour quelle que soit la méthode d'auto-hébergement utilisée.
Q : Quelle est la stabilité des chemins d'accès aux classes dynamiques ?
R : La stabilité est optimale. Etant donné que toutes les entrées des plug-in requis sont remplacées par une entrée de conteneur de chemin d'accès aux classes, le chemin d'accès aux classes ne change pas.
Q : Quel avantage offrent les chemins d'accès aux classes dynamiques ?
R : Avec les chemins d'accès aux classes dynamiques, vous n'avez aucune décision cruciale à prendre concernant le style de l'auto-hébergement. S'il existe des projets binaires, les chemins d'accès aux classes sont résolus sous la forme de références de projet. Sinon, ils sont résolus sous la forme de fichiers JAR de plug-in externe. A mesure que des projets binaires sont ajoutés ou supprimés, les chemins d'accès aux classes prennent en compte les modifications et s'adaptent. Vous n'êtes donc plus obligé de modifier vous-même ces chemins d'accès. De plus, les autres équipes qui souhaitent extraire l'un de vos projets de CVS afin de les compiler ne sont pas tenus d'utiliser le même style d'auto-hébergement que vous.
Q : Etant donné que les composants PDE résolvent les chemins d'accès aux classes dynamiques, dois-je compter sur PDE pour effectuer la bonne procédure ?
R : En un mot, oui. Etant dynamique, le chemin d'accès aux classes est toujours calculé à la volée et non pas codé en dur dans le fichier .classpath (ce qui correspond à l'objectif recherché). Mais réfléchissez à ceci : PDE est doté d'un algorithme sophistiqué de calcul des chemins d'accès aux classes qui a pour but d'approcher aussi près que possible des conditions d'exécution réelles. Lors du développement, les données perçues par le compilateur JDT doivent correspondre le plus possible à celles que perçoivent les chargeurs de classes lors de l'exécution. Dans la plupart des cas, les composants PDE sont mieux à même que vous de tenir à jour votre chemin d'accès aux classes. Si vous devez ajuster manuellement le chemin d'accès aux classes pour pouvoir compiler, une erreur s'est sans doute glissée dans la configuration et il y a peu de chances que le plug-in fonctionne correctement (l'équipe SWT étant une exception à cet égard).
R : Mon équipe utilise des projets binaires pour l'auto-hébergement uniquement. Vais-je tout perdre si j'opte pour les chemins de classe dynamiques ?
R : Non. Vos choix en matière de solution d'auto-hébergement ne sont en aucun cas dictés par les chemins d'accès aux classes dynamiques. Ces derniers sont là uniquement pour résoudre les dépendances de plug-in dans le contexte donné.
Si vous continuez à importer des plug-in externes sous la forme de projets binaires, les chemins d'accès aux classes sont résolus, comme précédemment, sous la forme de références de projet.
Q : Que faire pour activer les chemins d'accès aux classes ?
R : Ne mettez à jour les chemins de classe de tous vos plug-ins 2.1 qu'une fois. Vous pourrez constater que les chemins d'accès aux classes sont plus courts et que toutes les références aux plug-in dépendants sont remplacées par une entrée de conteneur. Vous pouvez continuer à travailler. Veillez à vérifier les projets source dans le référentiel, y compris les fichiers .classpath modifiés.
Q : Je possède des entrées de chemin d'accès aux classes supplémentaires pour permettre la compilation des fichiers tasks/servlets/JSP Ant.
R : Dans le cadre du calcul des chemins d'accès aux classes, PDE prend en compte la propriété 'jars.extra.classpath'
du fichier build.properties. Si la configuration est correcte en vue de la génération, PDE génère le chemin d'accès aux classes approprié.
Q : Comment les entrées de chemin d'accès aux classes calculées de manière dynamique doivent-elles être utilisées ?
R : Dans l'éventualité, bien improbable, où il s'avérerait nécessaire de manipuler les entrées de chemin d'accès aux classes, accédez à l'onglet Propriétés>Chemin de génération Java >Bibliothèques. Développez l'objet 'Entrées de Dependencies requises' et manipulez ces dernières.
Q : Certaines entrées calculées pour les bibliothèques ne comportent pas de connexion source. Est-il possible de les ajouter manuellement ?
R : PDE calcule les connexions source de la plupart des bibliothèques. Dans certains cas très rares, la génération automatique des connexions source peut échouer en raison d'une non conformité des noms de fichiers zip. Vous pouvez connecter les sources manuellement pour ces entrées dans la boîte de dialogue des propriétés du chemin de génération.
Q : Les connexions source générées manuellement vont-elles être effacées lors du prochain calcul dynamique du chemin d'accès aux classes dans PDE ?
R : Non. PDE conserve la trace de ces opérations manuelles et les applique à nouveau une fois le calcul dynamique terminé, tant que les chemins des bibliothèques n'ont pas changé.
Q : Je développe des produits SWT. Puis-je utiliser les chemins d'accès aux classes dynamiques ?
R : Malheureusement non. L'équipe SWT possède une configuration d'auto-hébergement unique dans laquelle les chemins d'accès aux classes des différents environnements sont sauvegardés dans le référentiel et renommés en .classpath dans le projet en fonction de la plateforme utilisée. Ces développeurs doivent continuer à utiliser leurs propres méthodes d'auto-hébergement.