Eclipse inneholder en rekke strategier for å støtte flerbrukerinstallasjoner. Hver strategi passer til et bestemt scenario. Dette dokumentet dekker disse strategiene og beskriver når hver av dem skal brukes. Dokumentet er beregnet på produktingeniører som skal konfigurere et Eclipse-basert produkt for distribusjon, systemadministratorer som konfigurerer Eclipse-baserte produkter som skal brukes via et nettverk, og utviklere som er interessert i å opprette plugin-moduler som egner seg godt i slike konfigurasjoner.
Sist endret: 17. juni, 2005
Som beskrevet i artikkelen Kjøretidsalternativer for Eclipse er det tre forskjellige plasseringer som er viktige i sammenheng med distribuering av Eclipse i en flerbrukerinstallasjon:
Før Eclipse er kjørt første gang, er konfigurasjonsområdet stort sett en tom katalog. Denne plasseringen blir gradvis fylt opp av Eclipse-kjøretiden, og andre plugin-moduler, på tvers av Eclipse-sesjoner. Det meste av metadataene som Eclipse-kjøretiden inneholder (for eksempel plugin-avhengigheter, utvidelsesregisteret) blir skrevet under avslutningen av den første sesjonen. Hvis settet med installerte plugin-moduler ikke blir endret, er det ikke nødvendig å skrive noe data i de etterfølgende sesjonene. Vi sier at konfigurasjonen er initialisert. Når konfigurasjonen er i denne tilstanden, er det til og med mulig å skrivebeskytte konfigurasjonsområdet. Det kan være nyttig å skrivebeskytte konfigurasjonsområdet i scenarier med for eksempel konfigurasjoner som deles (mer om dette senere).
Kommandolinjealternativet -initialize
lar deg initialisere konfigurasjonsområdet uten at
Eclipse-applikasjonen må kjøres. Initialiseringsprosedyren tvinger gjennom opprettelse av alle metadata som blir
skrevet til konfigurasjonsplasseringen under den første Eclipse-sesjonen. Det er imidlertid andre filer i
konfigurasjonsområdet som bare opprettes ved behov. Eksempler:
Platform.asLocalURL(URL)
. Resultatet
er at hvis URLen refererer til en fil i en JAR-fil, blir den filen trukket ut til filsystemet under
konfigurasjonsområdet. Når en fil er trukket ut, vil etterfølgende kall til Platform.asLocalURL()
være i stand til å finne den, så den filen blir ikke trukket ut flere ganger. Et liknende (faktisk det
opprinnelige) scenario der Platform.asLocalURL
blir brukt, og som har de samme konsekvensene, dreier seg
om å sørge for at eksternt innhold (for eksempel en fil som er tilgjengelig via en http-URL) er tilgjengelig
lokalt.I disse tilfellene (og i andre som plugin-moduler fra en tredjepart kanskje introduserer), er ikke initialiseringsprosessen tilstrekkelig for fullt ut å initialisere konfigurasjonsområdet. Det vil fortsatt være behov for å skrive til konfigurasjonsområdet, selv om dette behovet har en tendens til å forsvinne etter som alle utføringsbanene i applikasjonen som medfører at det opprettes filer i konfigurasjonsområdet, blir besøkt. Det er bare etter det at en kan si at konfigurasjonsområdet er fullstendig initialisert, og at det ikke noen gang vil kreves skrivetilgang til det for at Eclipse skal kjøres.
Dette er i virkeligheten et enkeltbrukerscenario. Eclipse-installasjonen blir brukt av en enkeltbruker, og brukeren har alle tilgangsrettigheter til den. Som standard vil plasseringen av konfigurasjonsområdet være konfigurasjonskatalogen under installeringsstedet.
Prosedyren med å konfigurere dette scenariet krever bare at man passer på at brukeren har alle rettigheter til installeringsstedet.
I dette scenariet blir et enkelt installasjonsområde delt av mange brukere. Katalogen "configuration" under installasjonsområdet inneholder bare config.ini som leveres sammen med produktet (den er ikke initialisert). Hver bruker har sin egen frittstående konfigurasjonsplassering.
Konfigurasjonen for dette scenariet krever at installasjonsområdet skrivebeskyttes for vanlige brukere. Når brukere starter Eclipse, fører det til at konfigurasjonsområdet som standard automatisk blir en katalog under brukerens hjemmekatalog. Hvis det ikke blir gjort, vil alle brukere bruke samme plassering for konfigurasjonsområdet, og det støttes ikke.
Her deler ikke brukere bare et installasjonsområde, men også et hovedkonfigurasjonsområde. Brukere har likevel, som standard, egne private skrivbare konfigurasjonsområder. En brukers private konfigurasjonsområde blir overført til hovedkonfigurasjonen og vil ikke inneholde noen interessante data hvis hovedkonfigurasjonen er fullstendig initialisert og det ikke er gjort noen endringer i settet med plugin-moduler som skal installeres.
I dette scenariet initialiserer systemadministratoren hovedkonfigurasjonen (vanligvis under installeringsstedet), og passer på at hele installasjons- og konfigurasjonsområdet er skrivebeskyttet. Når brukere kjører Eclipse-baserte produkter fra det delte installeringsstedet, blir et lokalt konfigurasjonsområde automatisk behandlet og initialisert, siden de ikke har skrivetilgangsrettigheter til konfigurasjonsområdet under installasjonsområdet.
Jo mer initialisert den delte konfigurasjonen er, jo mindre behov er det for å opprette filer under den lokale konfigurasjonen.
Standardplasseringen for et privat konfigurasjonsområde er:
<user-home-dir>/.eclipse/<product-id>_<product-version>/configuration
Brukerens hjemmekatalog blir bestemt av Java-systemegenskapen user.home
. Produkt-IDen og versjonen
hentes fra produktets marker-fil .eclipseproduct
under Eclipse-installeringen.
Et konfigurasjonsområde som ikke er standard, kan defineres ved å oppgi systemegenskapen
osgi.configuration.area
. Denne egenskapen
kan defineres av sluttbrukeren, men det er enklere å definere den enten i
launcher.ini eller i config.ini i basiskonfigurasjonens plassering.
Plugin-moduler kan installeres i / fjernes fra delte konfigurasjoner. Endringene blir aktivert for brukerne neste gang Eclipse kjøres. Man må passe på at brukere som har den delte konfigurasjonen som hovedkonfigurasjon, ikke kjører Eclipse.
Brukere kan endre de lokale konfigurasjonsområdene ved å installere andre plugin-moduler. Dette fører ikke til endringer i den delte konfigurasjonen, så andre brukere ser ikke endringene. Legg merke til at plugin-moduler som er konfigurert i konfigurasjonen som deles, ikke kan fjernes. Hvis de blir fjernet, blir de installert på nytt neste gang plattformen starter.