Styring af Eclipses opdateringspolitik

Med opdateringsfunktionen i Eclipse kan brugerne søge efter opdateringer af de aktuelt installerede funktioner. For alle installerede funktioner bruger opdateringsfunktionen den indbyggede URL til at oprette forbindelse til den eksterne server og søge efter nye versioner. Hvis der er opdateringer, giver Eclipse brugerne mulighed for at starte installationen. Efter overførsel, installation og genstart af platformen er den nye funktionsversion klar til brug.

I firmaer med mange brugere af det samme Eclipse-baserede produkt (typisk et kommercielt) kan der opstå flere problemer med denne model:

  1. Opdateringer til meget store produkter (f.eks. 500 eller flere plugins) er også store. It-afdelingen bryder sig muligvis ikke om, at hundredvis af udviklere individuelt overfører 500 MB opdateringer til deres individuelle computere. Ud over båndbreddeproblemer kan der opstå fejl, når data i disse mængder overføres, hvilket kan medføre gentagne forsøg og øget nedetid for udviklerne.
  2. Nogle firmaer ønsker ikke, at udviklerne skal overføre opdateringer direkte fra internettet. Det er f.eks. muligt, at den lokale supportafdeling ikke er klar til at håndtere anmodninger, der vedrører den version af produktet, som allerede findes på udbyderens opdateringswebsted. De vil måske begrænse opdateringer og programrettelser til den internt godkendte liste. Ideelt set gør de det ved at konfigurere "proxy"-opdateringswebsteder på LAN-netværket (bag ved firewall'en).
  3. Når administratorerne har konfigureret opdateringer på proxywebstederne som angivet ovenfor, har de brug for en metode til at fortælle brugerne, at der er tilgængelige opdateringer.

2. Opdateringspolitik kommer til undsætning

2.1 Mulighed for oprettelse af lokale (proxy-)opdateringswebsteder

Det første, en produktadministrator skal gøre, er at konfigurere et lokalt Eclipse-opdateringswebsted på en server, der har forbindelse til firmaets LAN-netværk (bag ved firewall'en). Opdateringswebstedet bør være en delmængde af produktets opdateringswebsted på internettet, fordi det skal kun indeholde funktioner og plugins, der vedrører de opdateringer, som firmaet ønsker anvendt i øjeblikket. Teknisk set kan dette websted være et almindeligt Eclipse-opdateringswebsted med site.xml, funktions- og plugin-arkiver.

Administratoren kan konstruere webstedet på to måder:

  1. De forskellige produktsupportteam kan oprette en zip-fil med opdateringswebstedet, som er lige klar til dette bestemte formål. Administratoren skal så blot overføre zip-filen fra produktsupportwebsiden vha. et selvvalgt værktøj og pakke den ud på den lokale server. Denne metode er nyttig ved meget store zip-filer, der kræver moderne overførselsstyring, som kan startes igen (den type, der kan fortsætte, hvor den slap i tilfælde af problemer med forbindelsen).
  2. Opdateringsfunktionen i Eclipse indeholder et værktøj, som spejler eksterne opdateringswebsteder fuldstændigt eller giver administratorer mulighed for at vælge opdateringer og programrettelser, de gerne vil overføre. Denne spejlingsmulighed er fuldt automatiseret og medfører en stor forenkling af administratorens arbejde, men den kræver, at opdateringsfunktionen understøtter netværksforbindelsen.

2.2 Fælles styring af opdateringspolitik

Da funktionerne har URL'en til opdateringswebstedet indbygget i manifestet, kender de ikke til de lokale opdateringswebsteder, som administratoren har konfigureret. Det er derfor vigtigt at give mulighed for omdirigering. Denne og andre opdateringspolitikindstillinger kan angives for et Eclipse-produkt ved at oprette en opdateringspolitikfil og konfigurere opdateringsfunktionen til at bruge denne fil ved søgninger.

Den pågældende fil bruger XML-format og kan have et hvilket som helst navn. Filen kan angives i Indstillinger > Installér/opdatér i feltet Opdateringspolitik. Tekstfeltet er som standard tomt: brugerne kan angive URL'en til opdateringspolitikfilen. Filen administreres af den lokale administrator og er fælles for alle produktinstallationer. Deling kan udføres på to måder:

Politikfilen skal overholde følgende DTD:

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

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

<!ELEMENT url-map EMPTY>
<!ATTLIST url-map
    mønster    CDATA #REQUIRED
    url        CDATA #REQUIRED
>

url-map

Dette element bruges til at tilsidesætte opdaterings-URL'er, som indbygget i funktionsmanifester. Når Eclipse søger efter nye opdateringer, kontrollerer programmet opdateringspolitikken (hvis den findes), samt om url-map for det tilsvarende funktionspræfiks er angivet. Hvis der findes en match, bliver den URL, som er tilknyttet vha. mapping, brugt i stedet for den indbyggede. På denne måde kan en administrator konfigurere Eclipse-produkter til at søge efter opdateringer på den lokale server bag ved firewall'en. I mellemtiden vil tredjepartsfunktioner, installeret af Eclipse Update, fortsat blive opdateret vha. standardmekanismen, fordi der ikke findes matcher i politikken.

Der kan være flere url-map-elementer i filen. Funktionspræfikser kan vælges til at være mere eller mindre specifikke. Hvis f.eks. alle Eclipse-opdateringer skal omdirigeres, skal mønsterattributten f.eks. være "org.eclipse". Tilsvarende er det muligt at bruge en komplet funktions-id som mønster, hvis omdirigering skal ske fra funktion til funktion.

Mønstre i filen kan vælges for at indsnævre de potentielle matcher progressivt. Det kan resultere i flere matcher for en bestemt funktion. I så fald anvendes matchen med det længste mønster. Eksempel:

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

I ovenstående eksempel bliver alle Eclipse-funktioner opdateret fra URL1, bortset fra org.eclipse.jdt, der bruger URL2.

Opdateringspolitikfiler indeholder ikke strenge, der kan oversættes, og derfor kræver de ikke særlig NL-håndtering. Generelt bør filerne anvende UTF-8-kodning.

2.3 Automatisk registrering af opdateringer

Det tredje element i den overordnede løsning er beskrevet i et andet emne, men nævnes her, fordi det er en integreret del af løsningen. Vha. Automatiske opdateringer kan Eclipse udføre opdateringssøgning efter en angivet tidsplan (hver gang der startes (standard), en gang om dagen, en gang om ugen osv.).

3. Resumé

Her er en komplet oversigt over de trin, som løsningen består af:

  1. Administrator allokerer en server på firmaets LAN til at være vært for lokale produktopdateringer. Til at begynde med indeholder den ingen opdateringswebsteder. Computeren skal have en aktiv HTTP-server.
  2. Administrator konfigurerer en opdateringspolitikfil på serveren og instruerer alle brugere i at angive indstillingen for opdateringspolitik til den leverede URL.
  3. Når produktudbyderen udsender opdateringer og programrettelser på deres opdateringswebsteder, overfører administrator understøttede opdateringer til den lokale server.
  4. Automatiske opdateringer, der udføres med den planlagte frekvens, henter de lokale opdateringer og giver brugeren besked.
  5. Brugeren vælger at installere de registrerede opdateringer.

Relaterede opgaver
Automatiske opdateringer - planlægningsprogram