Kontrollere oppdateringspolicyen for Eclipse

Med oppdateringsfunksjonen i Eclipse kan brukere søke etter oppdateringer for funksjonene de har installert. For hver funksjon som er installert, brukes den innebygde URL-adressen til å koble til den eksterne serveren og søke etter nye versjoner. Hvis det finnes oppdateringer, kan brukeren starte installeringen. Etter at plattformen er lastet ned, installert og startet på nytt, er den nye funksjonsversjonen klar for bruk.

I selskaper der flere brukere har det samme Eclipse-baserte produktet (vanligvis et kommersielt produkt) kan imidlertid denne modellen by på flere problemer:

  1. Omfattende produkter (for eksempel 500+ plugin-modulene) innebærer også omfattende oppdateringer. Det er ikke sikkert at IT-avdelingen ønsker at flere hundre utviklere skal laste ned oppdateringer på 500 MB på sine respektive maskiner. I tillegg til belastningen på båndbredden kan slike store oppdateringsforespørsler mislykkes, noe som resulterer i gjentatte forsøk og økt nedetid for utviklerne.
  2. Noen selskaper uttrykker klart at de ikke ønsker at utviklerne deres skal laste ned oppdateringer direkte fra Internett. De kan for eksempel opprette en lokal støttegruppe som ikke kan behandle forespørsler angående den versjonen av produktet som allerede er tilgjengelig på leverandørens oppdateringssted. De ønsker å begrense oppdateringer og rettelser mot en liste som er godkjent internt. Dette kan gjøres ved å opprette et proxy-oppdateringssted på lokalnettet (bak brannmuren).
  3. Når oppdateringene er definert på disse proxy-stedene må administratorene gi brukerne beskjed om at det finnes tilgjengelige oppdateringer.

2. Oppdateringspolicy for ressurs

2.1 Støtte for opprettelse av lokale oppdateringssteder (proxy)

Det første produktadministratoren må gjøre, er å konfigurere et lokalt Eclipse-oppdateringssted på en server som er tilkoblet selskapets lokalnett (bak brannmuren). Oppdateringsstedet er underordnet produktets oppdateringssted på Internett ettersom det bare kan inneholde funksjoner og plugin-moduler for oppdateringer som selskapet ønsker å bruke nå. Rent teknisk er dette et vanlig Eclipse-oppdateringssted med arkiver for site.xml, funksjoner og plugin-moduler.

Administratorer kan utforme dette stedet på to måter:

  1. Produktstøttegrupper kan lage en .zip-fil av oppdateringsstedet som skal brukes til dette bestemte formålet. Administratorer trenger bare å laste ned .zip-filen fra web-siden for produktstøtte ved hjelp av et verktøy de velger selv, og pakke ut filen på den lokale serveren. Dette alternativet er nyttig når .zip-filene er store og krever moderne nedlastingsstyrere som kan startes på nytt, i tilfelle det oppstår tilkoblingsproblemer.
  2. Oppdateringsfunksjonen i Eclipse inneholder et verktøy som fullt ut gjenspeiler innholdet på eksterne oppdateringssteder eller lar administratorer velge hvilke oppdateringer og rettelser som skal lastes ned. Speilingsfunksjonen er helt automatisert og gjør administratorens oppgaver mye enklere, men er avhengig av nettverkstilkobling for oppdateringsfunksjonen.

2.2 Vanlig policykontroll for oppdatering

Funksjonene bruker URL-adressen for oppdateringsstedet som er innebygd i manifestet, og ikke de lokale oppdateringsstedene som administratorene har angitt. Det er derfor viktig å bruke omdirigeringfunksjonalitet. Denne og andre innstillinger for oppdateringspolicy kan defineres for et Eclipse-produkt ved å opprette en fil for oppdateringspolicy og konfigurere oppdateringsfunksjonen til å bruke den filen ved søking.

Den aktuelle filen er i XML-format og kan ha et hvilket som helst navn. Filen kan oppgis i Preferanser > Installer/oppdater i feltet Oppdateringspolicy. Standard er at tekstfeltet er tomt. Brukere kan definere URL-adressen i filen for oppdateringspolicy. Filen håndteres av den lokale administratoren og deles på tvers av alle produktinstalleringer. Delingen kan foretas på to måter:

Policyfilen må være i samsvar med følgende DTD:

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

Dette elementet brukes til å overstyre URL-adresser som er innebygd i funksjonsmanifester for oppdateringsfunksjonen. Når det letes etter oppdateringer, sjekker Eclipse oppdateringspolicyen (hvis den finnes) og om det er oppgitt url-map for det samsvarende funksjonsprefikset. Hvis det er samsvar, brukes den tilordnede URLen i stedet for den innebygde URLen. Dermed kan administratorer konfigurere Eclipse-produkter slik at det søkes etter oppdateringer i den lokale serveren bak brannmuren. Samtidig kan tredjeparts funksjoner som er installert av oppdateringsfunksjonen i Eclipse, fortsatt oppdateres ved hjelp av standardmekanismen ettersom det ikke vil være samsvar med policyen.

Det kan finnes flere url-map-elementer i filen. Du kan velge om funksjonsprefikser skal være mer eller mindre spesifikke. Hvis for eksempel alle Eclipse-oppdateringer skal omdirigeres, brukes mønsterattributtet "org.eclipse". På samme måte er det mulig å bruke en komplett funksjons-ID som mønster hvis det er nødvendig med omdirigering for hver enkelt funksjon.

Det kan velges mønster i filen for å begrense potensielle samsvar. Dette kan resultere i flere samsvar for en gitt funksjon. I slike tilfeller brukes det samsvaret som har lengst 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 eksempelet ovenfor vil alle Eclipse-funksjoner bli oppdatert via URL1, bortsett fra org.eclipse.jdt, som bruker URL2.

Filer for oppdateringspolicy inneholder ikke strenger som kan oversettes, og krever derfor ingen bestemt NL-håndtering. Generelt bør filene bruke UTF-8-koding.

2.3 Automatisk søking etter oppdateringer

Du finner mer informasjon om dette under et annet emne, men vi nevner det likevel her fordi det er en integrert del av løsningen. Med Automatiske oppdateringer kan Eclipse søke etter oppdateringer i henhold til en definert tidsplan (ved oppstart (dette er standardverdien), en gang per dag, en gang per uke osv.).

3. Sammendrag

Her viser vi den komplette rekkefølgen av trinn som inngår i løsningen:

  1. Administratoren tildeler en server på selskapets lokalnett som er vert for lokale produktoppdateringer. Serveren inneholder i utgangspunktet ingen oppdateringssteder. Maskinen må ha en HTTP-server som kjører.
  2. Administratoren definerer en fil for oppdateringspolicy på serveren og instruerer alle brukerne om å angi preferansen for oppdateringspolicy med den oppgitte URL-en.
  3. Når produktleverandøren leverer oppdateringer og rettelser på sine oppdateringssteder, laster administratoren ned oppdateringer som støttes, til den lokale serveren.
  4. Automatisk oppdatering, som utføres med angitt intervall når klientens produkt kjører, henter de lokale oppdateringene og gir brukeren beskjed om dette
  5. Brukeren installerer oppdateringene som ble funnet

Beslektede oppgaver
Planleggingsfunksjon for automatisk oppdatering