I Eclipse finns ett antal strategier för att ge möjlighet till fleranvändarinstallationer. Varje strategi tillgodoser ett visst scenario. I det här dokumentet beskrivs de här strategierna och när var och en av dem bör användas. De avsedda läsarna är produktingenjörer som konfigurerar Eclipse-baserade produkter för distribution, systemadministratörer som installerar Eclipse-baserade produkter som ska användas via ett nätverk och utvecklare som är intresserade av att skapa insticksprogram som medverkar på ett välfungerande sätt i sådana installationer.
Senast ändrad: 17 juni 2005
Det finns tre olika platser som är viktiga för utplacering av Eclipse i en fleranvändarinstallation (mer information finns i avsnittet Eclipse Runtime-alternativ):
Innan Eclipse har körts för första gången är konfigurationsområdet i stort sett en tom katalog. Den fylls allt eftersom på av Eclipse Runtime och andra insticksprogram via olika Eclipse-sessioner. De flesta metadata som sparas i Eclipse Runtime (till exempel insticksprogramsberoenden, utökningsregistret) skrivs när den första sessionen stängs. Om inga ändringar görs i uppsättningen installerade insticksprogram behövs det inte skrivas några data under efterföljande sessioner. Vi säger att konfigurationen är initierad. När konfigurationen är i det läget går det till och med att ange att konfigurationsområdet ska vara skrivskyddat. Det kan vara praktiskt att ange att konfigurationsområdet ska vara skrivskyddat till exempel i scenarion med delade konfigurationer (mer om det senare).
Med hjälp av kommandoradsalternativet -initialize
går det att initiera konfigurationsområdet utan att en Eclipse-tillämpning måste köras. Initieringsproceduren tvingar fram att metadata som skrivits till konfigurationsplatsen under den första Eclipse-sessionen skapas. Det kan dock finnas andra filer i konfigurationsområdet som har skapats efter behov. Exempel:
Platform.asLocalURL(URL)
. Resultatet blir att om URL-adressen refererar till en fil i en JAR-fil extraheras den filen till filsystemet i konfigurationsområdet. När en fil extraheras kan efterföljande anrop till Platform.asLocalURL()
hitta den, vilket innebär att det inte kommer att göras några flera extraheringar för den filen. Ett liknande (i själva verket det ursprungliga) scenario där Platform.asLocalURL
används, och som har samma konsekvenser, är relaterat till att se till att fjärrinnehåll (till exempel en fil som kan öppnas via en http-URL-adress) är tillgängligt lokalt.I de fallen (och andra som tredjepartsinsticksprogram kan introducera) är initieringsproceduren inte tillräcklig för att till fullo initiera konfigurationsområdet. Det kommer fortfarande att finnas behov av att skriva till konfigurationsområdet även om de kommer att minska allt eftersom de körningssökvägar i tillämpningen som gör att filer skapas i konfigurationsområdet besöks. Endast därefter kan det sägas att konfigurationsområdet är fullständigt initierat och det kommer då inte att krävas skrivåtkomst till det för körning av Eclipse.
Det här är i själva verket ett enanvändarscenario. Eclipse-installationen används av en enskild användare och användaren har fullständig åtkomstbehörighet till den. Konfigurationskatalogen på installationsplatsen används som plats för konfigurationsområdet som standard.
Proceduren med att konfigurera det här scenariot är endast att kontrollera att användaren har fullständig behörighet till installationsplatsen.
I det här scenariot delas ett installationsområde av flera användare. Katalogen "configuration" i installationsområdet är hemkatalog endast för config.ini som levererades med produkten (den är inte initierad). Alla användare har sina egna lokala fristående konfigurationsplatser.
I konfigurationen för det här scenariot måste installationsområdet anges vara skrivskyddat för vanliga användare. När användare startar Eclipse används automatiskt en katalog i användarens hemkatalog som konfigurationsområde som standard. Om den här åtgärden inte vidtas kommer alla användare att använda samma plats för konfigurationsområdet vilket inte fungerar.
Här delar användare inte bara ett installationsområde utan även ett huvudkonfigurationsområde. Användare har ändå, som standard, enskilda privata skrivbara konfigurationsområden. En användares privata konfigurationsområde överförs till huvudkonfigurationen och innehåller inte några intressanta data om huvudkonfigurationen har initierats fullständigt och inga ändringar av uppsättningen insticksprogram som ska installeras har gjorts.
I det här scenariot initierar systemadministratören huvudkonfigurationen (vanligen på en installationsplats) och kontrollerar att hela installations- och konfigurationsområdena är skrivskyddade för användare. När användare kör den Eclipse-baserade produkten från den delade installationsplatsen beräknas och initieras ett lokalt konfigurationsområde automatiskt, eftersom användarna inte har skrivbehörighet till konfigurationsområdet i installationsområdet.
Ju mer fullständigt initierad den delade konfigurationen är desto mindre är behovet av att skapa filer i den lokala konfigurationen.
Standardplats för ett privat konfigurationsområde är:
<user-home-dir>/.eclipse/<product-id>_<product-version>/configuration
Hemkatalogen bestäms av Java-systemegenskapen user.home
.
Produkt-ID och -version hämtas från produktmarkeringsfilen .eclipseproduct
i Eclipse-installationen.
Du kan ange ett annat konfigurationsområde än standardområdet genom att ange systemegenskapen osgi.configuration.area
. Den egenskapen kan anges av slutanvändaren men det är mer praktiskt att ange den antingen i filen launcher .ini eller i filen config.ini på grundkonfigurationsplatsen.
Insticksprogram kan installeras i/tas bort från den delade konfigurationen. Användare får ta del av de ändringarna nästa gång Eclipse körs. Det är nödvändigt att kontrollera att användare som använder den delade konfigurationen som huvudkonfiguration inte kör Eclipse.
Användare kan ändra lokala konfigurationsområden genom att installera fler insticksprogram. Det innebär inte några ändringar av den delade konfigurationen så andra användare märker inte de ändringarna. Observera att det inte går att ta bort insticksprogram som konfigurerats i den delade konfigurationen. Om de tas bort installeras de på nytt nästa gång plattformen startas.