Steuerung für Aktualisierungsrichtlinie in Eclipse

Eclipse Update ermöglicht es Benutzern, nach Aktualisierungen der aktuell installierten Features zu suchen. Für jedes installierte Feature verwendet Update die eingebettete URL, um eine Verbindung zum fernen Server herzustellen und nach neuen Versionen zu suchen. Falls Aktualisierungen vorhanden sind, ermöglicht Eclipse den Benutzern, das Installationsverfahren einzuleiten. Nach dem Herunterladen, Installieren und erneuten Starten der Plattform ist die neue Featureversion verfügbar.

In Unternehmen, in denen viele Benutzer dasselbe Eclipse-basierte Produkt verwenden (normalerweise ein kommerzielles Produkt), können bei diesem Modell mehrere Probleme auftreten:

  1. Aktualisierungen für sehr große Produkte (z. B. 500+ Plug-ins) sind ebenfalls sehr groß. I/T-Supportteams gefällt möglicherweise die Idee nicht, dass Hunderte von Entwicklern einzelne 500MEG-Aktualisierungen für ihre jeweiligen Systeme herunterladen. Zusätzlich zu der Belastung der Bandbreite besteht bei derart großen Downloadanforderungen die Gefahr von Fehlern, was zu wiederholten Versuchen und einer höheren Ausfallzeit von Entwicklern führt.
  2. Einige Unternehmen wünschen es explizit nicht, dass die Entwickler Aktualisierungen direkt aus dem Internet herunterladen. Sie können beispielsweise ein lokales Supportteam einrichten, das möglicherweise nicht in der Lage ist, Anforderungen hinsichtlich der Version des Produkts, die bereits auf der Update-Site des Anbieters verfügbar ist, zu bearbeiten. Sie möchten möglicherweise Aktualisierungen und Korrekturen auf eine intern genehmigte Liste beschränken. Idealerweise würden sie dazu 'Proxy'-Updates-Sites über das LAN (hinter der Firewall) einrichten.
  3. Sobald Aktualisierungen auf den Proxy-Sites wie vorstehend beschrieben eingerichtet sind, müssen die Administratoren den Benutzern mitteilen, dass Aktualisierungen verfügbar sind.

2. Aktualisierungsrichtlinie für den Notfall

-2.1 Support für das Erstellen von lokalen (Proxy)Update-Sites

Der erste Schritt für einen Produktadministrator wäre die Einrichtung einer lokalen Eclipse Update-Site auf einem Server, der mit dem LAN des Unternehmens verbunden ist (hinter dem Firewall). Die Update-Site wäre eine Untergruppe der Update-Site des Produkts im Internet, da sie nur Features und Plug-ins enthalten würde, die mit den Aktualisierungen, die das Unternehmen zum jeweiligen Zeitpunkt anwenden möchte, in Verbindung stehen. Technisch wäre diese Site eine reguläre Eclipse Update-Site mit site.xml, Feature- und Plug-in-Archiven.

Administratoren können diese Site auf zwei Arten erstellen:

  1. Produkt-Supportteams können eine komprimierte Datei der bereits für diesen besonderen Zweck zur Verfügung stehenden Update-Site erstellen. Die Administratoren müssten lediglich die komprimierte Datei von der Webseite des Produktsupports mit einem von ihnen gewählten Tool herunterladen und sie auf dem lokalen Server dekomprimieren. Diese Strategie ist für äußerst große komprimierte Dateien nützlich, die moderne wieder anlauffähige Downloadmanager benötigen (denen eine Wiederaufnahme möglich ist, wenn sie bei Verbindungsproblemen unterbrochen werden).
  2. Eclipse Update enthält ein Tool, mit dem ferne Update-Sites vollständig gespiegelt werden können und die es Administratoren ermöglichen, Aktualisierungen und Korrekturen zum Download auszuwählen. Diese Spiegelungsfunktion ist vollkommen automatisch und vereinfacht die Task der Administratoren stark, doch sie hängt von dem Update-Netzwerkverbindungssupport ab.

2.2 Allgemeine Steuerung für Aktualisierungsrichtlinie

Da bei den Features die Update-Site-URL im Manifest eingebettet ist, sind ihnen lokale, von den Administratoren eingerichtete Update-Sites nicht bekannt. Deshalb ist es wichtig, eine Umleitungsfunktion bereitzustellen. Diese und andere Einstellungen von Aktualisierungsrichtlinien können für ein Eclipse-Produkt durch das Erstellen einer Aktualisierungsrichtliniendatei und der Konfiguration von Update zur Verwendung dieser Datei bei der Suche eingerichtet werden.

Die betreffende Datei verwendet das XML-Format und kann einen beliebigen Namen haben. Die Datei kann in Benutzervorgaben>Installation/Update in dem Feld Aktualisierungsrichtlinie eingerichtet werden. Das Textfeld ist standardmäßig leer: Die Benutzer können die URL für die Aktualisierungsrichtliniendatei einrichten. Die Datei wird von dem lokalen Administrator verwaltet und wird für alle Produktinstallationen verwendet. Die gemeinsame Nutzung kann auf zwei Arten erzielt werden:

Die Richtliniendatei muss der folgenden DTD entsprechen:

<?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

Dieses Element wird verwendet, um die in Featuremanifesten eingebetteten Update-URLs zu überschreiben. Bei der Suche nach neuen Aktualisierungen prüft die Eclipse-Suchfunktion die Aktualisierungsrichtlinie (wenn vorhanden) und prüft, ob url-map für das Präfix des übereinstimmenden Features angegeben ist. Falls eine Übereinstimmung gefunden wird, wird die zugeordnete URL statt der eingebetteten URL verwendet. Dadurch können die Administratoren Eclipse-Produkte so konfigurieren, dass sie nach Aktualisierungen auf dem lokalen Server hinter der Firewall suchen. Unterdessen werden von Eclipse Update installierte Features von Fremdanbieter weiter mithilfe der Standardmechanismen aktualisiert, da sie keine Übereinstimmungen in der Richtlinie finden.

In der Datei können mehrere url-map-Elemente vorhanden sein. Featurepräfixe können mehr oder weniger spezifisch gewählt werden. Um beispielsweise alle Eclipse-Updates umzuleiten, müsste das Musterattribut"org.eclipse" lauten. Entsprechend ist es möglich eine komplette Feature-ID als Muster zu verwenden, wenn die Umleitung auf der Grundlage je Feature erforderlich ist.

In der Datei enthaltende Muster können so gewählt werden, dass potenzielle Übereinstimmungen zunehmend verengt werden. Dies kann zu mehreren Übereinstimmungen für ein bestimmtes Feature führen. In diesem Fall wird die Übereinstimmung mit dem längsten Muster verwendet. Beispiel:

<?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>

Im vorstehenden Fall werden alle Eclipse-Features von URL1 aktualisiert, mit Ausnahme von org.eclipse.jdt, die URL2 verwendet.

Aktualisierungsrichtliniendateien enthalten keine übersetzbaren Zeichenfolgen und erfordern deshalb keine besondere NL-Verarbeitung. Im Allgemeinen verwenden die Dateien die UTF-8-Codierung.

A2.3 Automatisches Erkennen von Aktualisierungen

Automatische Aktualisierungen ermöglichen Eclipse, Update-Suchvorgänge nach einem bestimmten Zeitplan durchzuführen (bei jedem Start (Standard), einmal täglich, einmal wöchentlich, etc.).

3. Übersicht

Hier finden Sie eine komplette Aufstellung der Schritte, aus denen sich die Lösung zusammensetzt:

  1. Die Administratoren legen einen Server auf der LAN eines Unternehmens für das Hosting von lokalen Produktupdates an. Anfangs sind keine Update-Sites enthalten. Auf dem System muss ein HTTP-Server aktiv sein.
  2. Der Administrator richtet eine Aktualisierungsrichtliniendatei auf dem Server ein und weist alle Benutzer an, die bereitgestellte URL in den Benutzervorgaben der Aktualisierungsrichtlinie einzurichten.
  3. Wenn die Produktanbieter Aktualisierungen und Korrekturen auf ihren Update-Sites bereitstellen, lädt der Administrator unterstützte Aktualisierungen auf den lokalen Server herunter.
  4. Automatische Aktualisierungen, die mit einer zeitlich festgelegten Frequenz ausgeführt werden, wenn das Produkt des Client aktiv ist, nehmen die lokalen Aktualisierungen auf und benachrichtigen die Benutzer.
  5. Der Benutzer wählt die Installation der festgestellten Aktualisierungen.