Steuerung für Eclipse-Aktualisierungsrichtlinie

Eclipse-Update ermöglicht dem Benutzer die Suche nach Updates für die gegenwärtig installierten Features. Bei jedem installierten Featureverwendet Update die eingebettete URL, um die Verbindung zu dem fernen Server herzustellen und nach neuen Versionen zu suchen. Wenn Updates vorhanden sind, ermöglicht Eclipse dem Benutzer, das Installationsverfahren zu initialisieren. Nach dem Download, der Installation und dem Neustart der Plattform ist die neue Version des Features einsatzbereit.

In Unternehmen mit vielen Benutzern desselben, auf Eclipse basierenden Produkts (typischerweise ein kommerzielles Unternehmen), können sich aus diesem Modell einige Probleme ergeben:

  1. Updates für sehr große Produkte (z.B. 500 und mehr Plug-ins) sind auch groß. Die IT-Unterstützungsteams mögen die Vorstellung vielleicht gar nicht, dass Hunderte von Entwicklern einzeln 500 MB Updates auf ihre einzelnen Maschinen downloaden. Zusätzlich zu Belastung der Übertragungsleistung kann eine solche große Downloadanforderung fehlschlagen, zu wiederholten Versuchen führen und höhere Ausfallzeiten der Entwickler verursachen.
  2. In einigen Unternehmen ist es ausdrücklich untersagt, dass Entwickler Updates direkt aus dem Internet downloaden. So können sie z.B. ein lokales Support-Team einrichten, das noch nicht in der Lage ist, Anfragen in Bezug auf eine Produktversion zu beantworten, die bereits auf der Update-Site des Providers verfügbar ist. Sie möchten vielleicht Updates und Fixes auf die intern genehmigte Liste beschränken. Idealerweise würde dies dadurch geschehen, dass 'Proxy'-Update-Sites in dem LAN (hinter der Firewall) eingerichtet werden.
  3. Wenn Updates, wie oben genannt, auf den Proxy-Sites zur Verfügung gestellt worden sind, müssen die Administratoren den Benutzern mitteilen, dass Updates zur Verfügung stehen.

2. Update-Richtlinie 'zur Rettung'

2.1 Unterstützung für die Erstellung lokaler (Proxy-) Update-Sites

Der erste Schritt für eine Produktadministrator wäre, eine lokale Eclipse-Update-Site auf einem Server einzurichten, der an das LAN des Unternehmens(hinter der Firewall) angeschlossen ist. Bei der Update-Site würde es sich um eine Unterkomponente der Produkt-Update-Site im Internet handeln, da sie nur Features und Plug-ins in Bezug auf die Updates, die das Unternehmen im Moment angewandt sehen möchte, enthalten würde. Technisch wäre diese Site eine reguläre Eclipse-Update-Site mit site.xml, Features- und Plug-in-Archiv.

Administratoren würden diese Site auf zwei Weisen erstellen:

  1. Produktsupport-Teams würden zu diesem Zweck eine sofort verfügbare ZIP-Datei des Updates zur Verfügung stellen. Administratoren würden einfach die ZIP-Datei unter Verwendung eines Tools ihrer Wahl von der Produkt-Support-Website herunterladen und in den lokalen Server extrahieren. Diese Methode ist nützlich bei sehr großen ZIP-Dateien, die moderne, neustartfähige Download-Manager erfordern (d.h. solche, die den Download an der Stelle wieder aufnehmen, an der bei einem Verbindungsproblem unterbrochen wurde).
  2. Eclipse-Update stellt ein Tool zur Verfügung, mit dem ferner Update-Sites vollkommen gespiegelt werden können oder Administratoren auswählen können, welche Updates oder Fixes heruntergeladen werden sollen. Diese Funktionalität des Spiegelns wäre vollautomatisch und würde die Aufgaben des Administrators wesentlich erleichtern, aber es verlässt sich auf die Unterstützung durch eine Update-Netzwerkverbindung.

2.2 Allgemeine Steuerung für Eclipse-Aktualisierungsrichtlinie

Da Features die URL der Update-Site im Manifest eingebettet haben, sind ihnen die durch den Administrator eingerichteten Update-Sites nicht bekannt. Es ist daher wichtig, eine Umleitungsfunktion zur Verfügung zu stellen. Diese und andere Einstellungen der Update-Richtlinie können für ein Eclipse-Produkt festgelegt werden, indem eine Update-Richtliniendatei festgelegt wird und das Update so konfiguriert wird, dass diese Datei bei d er Suche verwendet wird.

Die in Frage kommende Datei verwendet das XML-Format und kann jeden beliebigen Namen haben. Diese Datei kann in Benutzervorgaben>Installieren/Update im Feld Update-Richtlinie festgelegt werden. Standardmäßig ist das Textfeld leer: Benutzer können die URL der Update-Richtliniendatei festlegen. Die Datei wird durch den lokalen Administrator verwaltet und wird für alle Produktinstallationen gemeinsam benutzt. Die gemeinsame Benutzung kann auf zwei Weisen realisiert werden:

Die Richtliniendatei muss mit der folgenden DTD übereinstimmen:

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

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

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

url-map

Dieses Element dient dazu, Update-URLs, die im Manifest des Features eingebettet sind, außer Kraft zu setzen. Bei der Suche nach neuen Updates prüft die Suchfunktion in Eclipse die Update-Richtlinie (wenn vorhanden) und prüft, ob url-map für das übereinstimmende Featurepräfix angegeben worden ist. Wenn eine Übereinstimmung gefunden wird, wird die zugeordnete URL anstelle der eingebetteten verwendet. Auf diese Weise können Administratoren Eclipse-Produkte so konfigurieren, dass nach Updates auf dem lokalen Server hinter der Firewall gesucht wird. Inzwischen werden Features von Fremdanbietern, die durch Eclipse-Update installiert werden, weiterhin unter Verwendung des standardmäßigen Verfahrens aktualisiert, da sie keine Übereinstimmungen in der Richtlinie finden werden.

Es können mehrere url-map-Elemente in der Datei vorkommen. Featurepräfixe können so ausgewählt werden, dass sie mehr oder weniger spezifis ch sind. Um zum Beispiel alle Eclipse-Updates umzuleiten, wäre das Attribut für 'Muster' "org.eclipse". In ähnlicher Weise ist es möglich, eine komplette Feature-ID als Muster zu verwenden, wenn die Umleitung auf Basis einzelner Features erforderlich ist.

Muster in der Datei können Sie ausgewählt werden, dass sie die potentiellen Übereinstimmungen schrittweise eingrenzen. Dies kann zu mehreren Übereinstimmungen für ein gegebenes 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 obigen Fall werden alle Eclipse-Features von URL1 aktualisiert, mit Ausnahme von org.eclipse.jdt, für das URL2 verwendet wird.

Update-Richtliniendateien enthalten keine übersetzbaren Zeichenfolgen und bedürfen daher keiner speziellen Behandlung in bezug auf Landessprachen. Im Allgemeinen sollten die Dateien die Codierung 'UTF-8' verwenden.

2.3 Automatische Erkennung von Updates

Der dritte Teil der Gesamtlösung wird unter einem anderen Stichwort behandelt, hier aber erwähnt, da es sich dabei um einen integralen Bestandteil der Lösung handelt. Automatische Updates ermöglichen Eclipse, eine Update-Suche nach einem festgelegten Plan auszuführen (bei jedem Start (Standard), einmal pro Tag, einmal pro Woche, usw.).

3. Zusammenfassung

Hier die komplette Reihenfolge der Schritte, die die Lösung darstellen:

  1. Der Administrator richtet einen Server im LAN des Unternehmens ein, der die Produkt-Updates aufnimmt. Anfänglich enthält er keine Update-Sites. Auf der Maschine muss ein HTTP-Server laufen.
  2. Der Administrator legt auf diesem Server eine Update-Richtliniendatei an und weist alle Benutzer an, die Benutzervorgabe der Update-Richtlinie a uf diese vorgegebene URL festzulegen.
  3. Wenn der Produkt-Provider Updates und Fixes auf seinen Update-Sites zur Verfügung stellt, lädt der Administrator die unterstützten Updates auf den lokalen Server herunter.
  4. Die in den festgelegten Intervallen durchgeführten automatischen Updates übernehmen die lokalen Updates und benachrichtigen den Benutzer.
  5. Der Benutzer wählt die Installation der aufgespürten Updates aus.

Verwandte Tasks
Scheduler für automatische Aktualisierungen