Contrôle des règles de mise à jour d'Eclipse

La fonction de mise à jour d'Eclipse permet aux utilisateurs de rechercher des mises à jour pour les fonctions installées. Pour chaque fonction installée, la fonction de mise à jour utilise l'URL imbriquée pour établir la connexion au serveur distant et rechercher de nouvelles versions. S'il existe des mises à jour, Eclipse permet aux utilisateurs de lancer la procédure d'installation. Après le téléchargement, l'installation et le redémarrage de la plateforme, la nouvelle version de la fonction peut être utilisée.

Dans les entreprises qui comptent de nombreux utilisateurs du même produit reposant sur Eclipse (un produit commercial en général), ce modèle peut entraîner plusieurs problèmes :

  1. Les mises à jour des produits de grande taille (comportant plus de 500 plug-ins) sont également importantes. Il se peut que les équipes de support technique n'aiment pas l'idée de centaines de développeurs téléchargeant chacun des mises à jour de 500 Mo sur leur machine. En plus de l'impact sur la largeur de bande, une telle demande de téléchargement peut échouer, entraînant plusieurs tentatives et l'augmentation de la durée d'immobilisation des développeurs.
  2. Certaines entreprises refusent explicitement que les développeurs téléchargent des mises à jour directement à partir d'Internet. Leur équipe de support locale peut ne pas être en mesure de répondre aux demandes liées à la version du produit déjà disponible sur le site de mise à jour du fournisseur. Elles peuvent établir une liste approuvée en interne des mises à jour et des correctifs autorisés. Idéalement, elles devraient le faire par le biais de sites de mises à jour 'proxy' sur le LAN (derrière le pare-feu).
  3. Une fois les mises à jour définies sur les sites proxy susmentionnés, les administrateurs doivent signaler aux utilisateurs que des mises à jour sont disponibles.

2. Règle de mise à jour

2.1 Support pour la création de sites de mises à jour (proxy) locaux

Pour un administrateur produit, la première étape consiste à créer un site de mise à jour Eclipse local sur un serveur connecté au réseau LAN de l'entreprise (derrière le pare-feu). Le site de mise à jour serait un sous-ensemble du site de mise à jour du produit sur Internet car il ne contiendrait que les fonctions et plug-ins liés aux mises à jour que l'entreprise souhaite appliquer pour le moment. Techniquement, il s'agirait d'un site de mise à jour Eclipse standard avec un fichier site.xml et des archives de plug-ins et de fonctions.

Les administrateurs peuvent créer ce site de deux façons.

  1. Les équipes de support du produit peuvent créer un fichier zip du site de mise à jour qu'ils peuvent ensuite mettre à disposition. Les administrateurs n'ont alors qu'à télécharger le fichier zip à partir de la page Web de support du produit avec l'outil de leur choix et le dézipper sur le serveur local. Cette approche est judicieuse pour les fichiers zip de très grande taille qui requièrent des gestionnaires de téléchargement redémarrables modernes (qui savent à quel endroit ils se sont arrêtés en cas de défaillance de la connexion).
  2. La fonction de mise à jour d'Eclipse met à disposition un outil qui permet de refléter les sites de mises à jour distants entièrement ou qui permet aux administrateurs de sélectionner les mises à jour et les correctifs à télécharger. Cette fonction de miroir pourrait être entièrement automatisée et simplifierait grandement la tâche de l'administrateur mais elle repose sur le support de connexion réseau de la fonction de mise à jour.

2.2 Contrôle des règles de mise à jour courantes

Etant donné que l'URL du site de mise à jour est imbriquée dans le manifeste des fonctions, ces dernières ne connaissent pas les sites de mises à jour définies par les administrateurs. Par conséquent, il est important de permettre la redirection. Vous pouvez définir ce paramètre de règle de mise à jour, ainsi que d'autres paramètres, pour un produit Eclipse, en créant un fichier de règles de mise à jour et en configurant la fonction de mise à jour de sorte qu'elle utilise ce fichier lors des opérations de recherche.

Le fichier en question utilise le format XML et vous pouvez lui attribuer le nom de votre choix. Le fichier peut être défini dans Préférences>Installation/Mise à jourdans la zone Règle de mise à jour. La zone de texte est vide par défaut : les utilisateurs peuvent définir l'URL du fichier de règles de mise à jour. Le fichier est géré par l'administrateur local et est partagé par toutes les installations du produit. Vous pouvez procéder au partage de deux façons :

Le fichier de règles doit être conforme au fichier DTD suivant :

<?xml encoding="ISO-8859-1"?>

<!ELEMENT update-policy (url-map)*>
<!ATTLIST update-policy
>

<!ELEMENT url-map EMPTY>
	pattern	CDATA #REQUIRED
	url	CDATA #REQUIRED
>

url-map

Cet élément permet de remplacer les URL de mise à jour imbriquées dans les manifestes des fonctions. Lors de la recherche de nouvelles mises à jour, Eclipse vérifie la règle de mise à jour (si elle existe) et s'assure que la valeur url-map pour le préfixe de la fonction correspondant est spécifiée. Si une occurrence est trouvée, l'URL mappée est utilisée à la place de l'URL imbriquée. De cette façon, les administrateurs peuvent configurer des produits Eclipse de sorte qu'ils effectuent la recherche des mises à jour sur le serveur local derrière le pare-feu. Pendant ce temps, les fonctions tierces installées par la fonction de mise à jour d'Eclipse continuent d'être mises à jour avec le mécanisme par défaut car elles ne trouveront pas d'occurrences dans la règle.

Plusieurs éléments url-map peuvent exister dans le fichier. Vous pouvez choisir des préfixes de fonction plus ou moins spécifiques. Par exemple, pour rediriger toutes les mises à jour Eclipse, l'attribut pattern est "org.eclipse". De même, vous pouvez utiliser un ID de fonction complet comme modèle si la redirection est requise pour chaque fonction.

Vous pouvez sélectionner les modèles qui figurent dans le fichier de sorte qu'ils limitent progressivement les résultats. Il se peut que vous obteniez plusieurs occurrences pour une fonction donnée. Dans ce cas, l'occurrence dont le modèle est le plus long est utilisée. Exemple :

<?xml version="1.0" encoding="UTF-8" ?>
<update-policy>
	<url-map pattern="org.eclipse" url="URL1"/>
	<url-map pattern="org.eclipse.jdt" url="URL2"/>
</update-policy>

Dans le cas ci-dessus, toutes les fonctions d'Eclipse sont mises à jour à partir d'URL1, sauf org.eclipse.jdt qui utilise URL2.

Les fichiers de règles de mise à jour ne contiennent pas de chaînes traduisibles et ne requièrent par conséquent aucun traitement spécial lié à la langue. En général, les fichiers utilisent un encodage UTF-8.

2.3 Reconnaissance automatique des mises à jour

La fonction de mise à jour automatique permet à Eclipse de rechercher les mises à jour à un moment précis (à chaque démarrage (par défaut), une fois par jour, une fois par semaine, etc)..

3. Récapitulatif

Séquence complète des étapes :

  1. Les administrateurs réservent un serveur sur le réseau LAN de l'entreprise pour l'hébergement des mises à jour du produit locales. Au départ, il n'existe pas de site de mise à jour. Un serveur HTTP doit s'exécuter sur la machine.
  2. Les administrateurs définissent un fichier de règles de mise à jour sur ce serveur et demandent aux utilisateurs de définir la préférence de règle de mise à jour avec l'URL fournie.
  3. Au fur et à mesure que le fournisseur du produit ajoute des mises à jour et des correctifs sur son site de mise à jour, l'administrateur télécharge les mises à jour prises en charge sur le serveur local.
  4. La fonction de mise à jour automatique planifiée lancée lorsque le client est en cours d'exécution applique les mises à jour locales et notifie l'utilisateur.
  5. Les utilisateurs choisissent d'installer ou non les mises à jour détectées.