Piattaforma Eclipse
Installazione e aggiornamento
Ultima revisione: 14/06/01 ore 10:45 - Versione: 0.12
Nota: il Gestore degli aggiornamenti è ancora in fase di sviluppo e pertanto verranno apportate certamente delle modifiche prima della sua versione definitiva. È stato reso disponibile in questa fase per sollecitare commenti e suggerimenti dai primi utenti, precisando che i dettagli relativi alla struttura di installazione potrebbero subire radicali modifiche. |
Introduzione
Scenari
Convenzioni di assemblaggio
Concetti
Archivio dei componenti
Archivio di configurazione
Conversione delle informazioni di assemblaggio
Considerazioni sulla sicurezza
Assemblaggio NL
Assemblaggio del supporto specifico per la destinazione
Assemblaggio file di supporto
Struttura di installazione
Differenze tra l'installazione completa e l'installazione di riferimento
Mapping di file system: installazione completa
File dell'area di lavoro
Mapping di file system: installazione di riferimento
Avvio della piattaforma Eclipse
Considerazioni sugli aggiornamenti
Aggiornamento di componenti estranei alla piattaforma
Aggiornamento della piattaforma
Aggiornamento dei file JRE
Aggiornamento dei file di prodotto
Aggiornamento del supporto di avvio
Ripristino in seguito all'interruzione di un aggiornamento
Ripristino in seguito a un aggiornamento non valido
Pulitura dell'installazione
Funzione Eclipse non gestita
Considerazioni sull'installazione
Nuova installazione
Installazione unita
Registrazione specifica per la piattaforma
Considerazioni sullo sviluppo
Indipendenza della posizione di installazione
Eseguibili nativi
Supporto per versioni contemporanee di plug-in
Migrazione di versione
Introduzione
Il presente documento delinea il supporto per gestire la distribuzione di funzioni nella piattaforma Eclipse.
Scenari
La piattaforma Eclipse prevede un gestore degli aggiornamenti incorporato, utilizzato come parte dell'installazione delle funzioni Eclipse, oltre che per la distribuzione di aggiornamenti di servizi e aggiornamenti di funzione. Gli scenari che seguono sono supportati nella versione precedente della piattaforma Eclipse:
-
Installazione tradizionale di nuovo prodotto
In questo scenario un prodotto realizzato con la piattaforma Eclipse viene assemblato utilizzando la tecnologia di installazione propria della piattaforma, come Windows MSI Installer, RPM, InstallShield
o un qualsiasi altro meccanismo di archiviazione, ad esempio un file .zip. L'assemblatore del prodotto segue le convenzioni di struttura del file Eclipse descritte di seguito (consultare "Mapping del file system: installazione completa"). Durante l'installazione, nel file system locale viene creata una struttura per l'installazione dei nuovi prodotti in cui vengono copiati i file assemblati; tra cui una copia della piattaforma Eclipse e, facoltativamente, l'ambiente Java jre e i plug-in di prodotto che verranno eseguiti sulla piattaforma Eclipse.
-
Installazione tradizionale unita
In questo scenario un prodotto realizzato con la piattaforma Eclipse viene assemblato utilizzando la tecnologia di installazione propria della piattaforma, come Windows MSI Installer, RPM, InstallShield
o un qualsiasi altro meccanismo di archiviazione, ad esempio un file .zip. L'assemblatore del prodotto segue le convenzioni di struttura del file Eclipse descritte di seguito (consultare "Mapping del file system: installazione completa"). Durante l'installazione, viene rilevato nel sistema una installazione precedente di Eclipse (consultare la sezione "Registrazione specifica per la piattaforma"). L'utente può scegliere se unire le nuove funzioni nell'installazione esistente o se installare le nuove funzioni come nuova installazione (scenario precedente).
Nel caso della semplice archiviazione, l'utente che esegue l'installazione seleziona manualmente la directory di installazione esistente, senza alcuna assistenza da parte dell'utilità di archiviazione, quale l'utilità zip.
-
Aggiornamento dei componenti
Il workbench Eclipse standard contiene una finestra che consente l'aggiornamento in rete dei componenti precedentemente installati. I metadati assemblati con ogni componente consentono alla procedura guidata di determinare la posizione del server di aggiornamento.
Per attivare gli aggiornamenti occorre riavviare la piattaforma Eclipse.
-
Aggiunta di nuovi componenti
Il workbench Eclipse standard contiene una finestra che consente di rilevare nuovi componenti e di aggiungerli in rete. Per attivare i componenti aggiunti occorre riavviare la piattaforma Eclipse.
Convenzioni di assemblaggio
Concetti
Plug-in
Gli sviluppatori Eclipse producono plug-in, le unità di base dell'esecuzione, riconosciute dall'ambiente run-time di Eclipse. In genere, i plug-in non vengono mostrati agli utenti al momento della selezione delle funzioni durante l'installazione o l'aggiornamento.
Questo perché i limiti dei plug-in vengono fissati dagli sviluppatori in base alle esigenze di progettazione (quali il riutilizzo delle funzioni) e non presentano un livello di granularità errato per quanto concerne ciò che l'utente rileva come unità della funzione.
Durante lo sviluppo dei plug-in, che vengono frequentemente modificati, la struttura dei file interni riporta le informazioni utili allo sviluppatore.
Ciò, in genere, dipende dallo strumento di sviluppo utilizzato.
Tuttavia, i plug-in quasi sempre vengono impostati per essere eseguiti da una struttura di directory contenente file .class, piuttosto che .jar, dal momento che questi richiedono un'ulteriore fase, volta alla creazione dei file .jar. Inoltre, in questa fase, per lo sviluppatore non hanno particolare importanza le informazioni sulla creazione delle versioni di plug-in, poiché questi vengono modificati continuamente.
Tuttavia, quando i plug-in sono pronti per l'assemblaggio, è necessario convertirli in un form che consente l'assemblaggio e l'installazione. In genere, questo avviene creando runtime .jar ed eliminando i file di sviluppo (file di origine, file .class esposti e così via). Viene inoltre aggiornato il manifest plugin.xml con la versione formale di plug-in, riportando la versione nel nome della directory di plug-in (per ulteriori informazioni, consultare "Supporto per versioni contemporanee di plug-in).
Frammenti di plug-in
Questi frammenti consentono l'assemblaggio indipendente di alcuni aspetti del plug-in di base. Tra questi, le risorse convertite per il plug-in, il codice per il sistema operativo o per i sistemi Window, il contenuto di plug-in specifico per diversi tipi di utenti, quali le informazioni per sviluppatori SDK fornite con un plug-in. Nella fase di avvio, i frammenti vengono uniti in modo logico nel plug-in di base. Per assemblaggio può intendersi sia l'inclusione fisica nel plug-in di base, sia un tipo di assemblaggio indipendente che ne consente un utilizzo separato. Ciò consente, ad esempio, la creazione di un "pacchetto di linguaggio" o di un particolare "pacchetto di sistema operativo" indipendenti rispetto alla distribuzione della funzione base.
Componente
Un componente è un insieme di plug-in o di frammenti di plug-in che distribuisce alcune funzioni utente. I componenti vengono mostrati agli utenti come parte del processo di installazione e di assemblaggio, dal momento che rappresentano un'unità per la selezione di funzioni, oltre che un'utilità di installazione (tutti i file contenuti vengono installati insieme in una struttura di installazione). I componenti riportano un identificativo di versione.
I componenti vengono assemblati come un .jar Java, contenente i plug-in necessari, i frammenti di plug-in e un manifest di installazione del componente e cioè un file xml.
I file .jar del componente possono essere posizionati su un server di aggiornamento per il download e l'installazione da parte del gestore degli aggiornamenti Eclipse oppure è possibile utilizzare i file .jar come input di un processo di assemblaggio formale, servendosi di una delle tecnologie di installazione tradizionali. Il formato dei file .jar del componente e il relativo manifest di installazione saranno descritti in seguito.
Configurazione
Una configurazione è un meccanismo di raggruppamento in versioni per un'insieme di componenti caratterizzati da una versione. Tale meccanismo consente, ad esempio, di specificare la configurazione dei componenti creati e sottoposti a test con una specifica versione di prodotto.
Le configurazioni sono assemblate come .jar Java, contenente il manifest di installazione della configurazione e cioè un file xml. Il manifest contiene i riferimenti ai componenti che costituiscono la configurazione, insieme ai vincoli di installazione e di aggiornamento della versione. Si noti che il file .jar non contiene ancora i file del componente, ma solo i riferimenti.
I file .jar di configurazione possono essere posizionati su un server di aggiornamento per il download e l'installazione da parte del gestore degli aggiornamenti Eclipse oppure è possibile utilizzare i file .jar come input di un processo di assemblaggio formale, servendosi di una delle tecnologie di installazione tradizionali. Il formato dei file .jar di configurazione e il relativo manifest di installazione saranno descritti in seguito.
L'attuale implementazione della piattaforma Eclipse non consente la nidificazione delle configurazioni.
Archiviazione dei componenti (.jar)
Per convenzione, i componenti sono identificati utilizzando un identificativo di struttura basato sul nome di dominio del provider Internet. Ad esempio, organization eclipse.org produce il componente org.eclipse.platform. L'identificativo del componente viene utilizzato come parte del nome del file .jar del componente, oltre che come nome della directory del componente nella struttura .jar (e di conseguenza nella struttura di installazione). Dal momento che possono essere installate contemporaneamente più versioni dello stesso componente, il nome del file .jar del componente e il nome della relativa directory, codificano anche l'identificativo della versione. Tale identificativo segue il formato definito dalla piattaforma Eclipse per gli identificativi di versione dei plug-in (consultare javadoc per la classe PluginVersionIdentifier). Tali identificativi sono costituiti da tre parti che indicano rispettivamente le configurazioni principali, secondarie e di servizio, ad esempio 2.4.11
Il nome è nel formato:
<componentId>_<version>
Ad esempio,
org.eclipse.platform_1.0.3.jar
com.ibm.tools.jspeditor_3.1.0\install.xml
Il jar del componente ha la seguente struttura di percorso interno:
install/
components/
<componentId>_<version>/
install.xml
(altri file opzionali) consultare "Conversione delle informazioni di assemblaggio"
plugins/
<pluginId>_<pluginVersion>/
plugin.xml
(altri file di plug-in)
fragments/
<fragmentId>_<fragmentVersion>/
fragment.xml
(altri file di frammento, tra cui plugin.xml)
Il file .jar contiene un percorso install/components/ e un file install.xml; zero o più plug-in nelle relative directory (con la qualifica di versione); zero o più frammenti di plug-in nelle relative directory (con la qualifica di versione); la directory meta-inf/ prodotta dalle utilità jar Java.
Il formato del componente install.xml viene definito dalla seguente dichiarazione DTD:
<?xml encoding="US-ASCII"?>
<!ELEMENT component (description?, url?, plugin*, fragment*)>
<!ATTLIST component
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
provider-name CDATA #IMPLIED
>
<!ELEMENT description (#PCDATA)>
<!ELEMENT url (update*, discovery*)>
<!ELEMENT update EMPTY>
<!ATTLIST update
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT discovery EMPTY>
<!ATTLIST discovery
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT plugin EMPTY>
<!ATTLIST plugin
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
>
<!ELEMENT fragment EMPTY>
<!ATTLIST fragment
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
>
Di seguito sono riportate le definizioni degli elementi e degli attributi:
-
<component> - definisce il componente
-
label - etichetta visualizzabile facoltativa (nome)
-
id - identificativo necessario del componente (ad esempio org.eclipse.platform)
-
version - versione necessaria del componente (ad esempio 1.0.3)
-
provider-name - etichetta facoltativa di visualizzazione, che identifica l'organizzazione che fornisce questo componente
-
<description> - breve descrizione del componente
-
<url> - URL facoltativo che specifica i siti che contengono aggiornamenti del componente o nuovi componenti.
-
<update> - URL cui collegarsi per aggiornare questo componente
-
url - URL corrente
-
label - etichetta visualizzabile (nome) del sito indicato
-
<discovery> - URL cui collegarsi per nuovi componenti o nuove configurazioni. In genere un provider utilizza questo elemento per fare riferimento al proprio sito o ai siti dei propri partner che offrono componenti o configurazioni complementari.
La piattaforma Eclipse utilizza questo elemento semplicemente per distribuire nuovi URL ai client.
-
url - URL corrente
-
label - etichetta visualizzabile (nome) del sito indicato
-
<plugin> - identifica il plug-in contenuto
-
label - etichetta facoltativa visualizzabile (nome) del plug-in contenuto
-
id - identificativo necessario del plug-in
-
version - versione necessaria del plug-in. Tale identificativo segue il formato definito dalla piattaforma Eclipse per gli identificativi di versione dei plug-in (consultare javadoc per la classe PluginVersionIdentifier).
-
<fragment> - identifica il frammento di plug-in contenuto
-
label - etichetta facoltativa visualizzabile (nome) del frammento di plug-in contenuto
-
id - identificativo necessario del frammento di plug-in. Si noti che l'identificativo di base del plug-in è una parte dell'identificativo del frammento (ad esempio, org.eclipse.platform_de_DE identifica come frammento il pacchetto di conversione della piattaforma tedesca)
-
version - versione necessaria del frammento di plug-in. Tale identificativo segue il formato definito dalla piattaforma Eclipse per gli identificativi di versione dei plug-in (consultare javadoc per la classe PluginVersionIdentifier).
Archiviazione di configurazione (.jar)
Per convenzione, le configurazioni sono identificate utilizzando un identificativo di struttura basato sul nome del dominio del provider internet. Ad esempio, organization eclipse.org produce la configurazione org.eclipse.sdk. L'identificativo della configurazione viene utilizzato come parte del nome del file .jar della configurazione, oltre che come nome della directory di configurazione nella struttura .jar (e di conseguenza nella struttura di installazione). Dal momento che possono essere installate contemporaneamente più versioni della stessa configurazione, il nome del file .jar della configurazione e il nome della relativa directory, codificano anche l'identificativo della versione. Tale identificativo segue il formato definito dalla piattaforma Eclipse per gli identificativi di versione dei plug-in (consultare javadoc per la classe PluginVersionIdentifier). Tali identificativi sono costituiti da tre parti che indicano rispettivamente le configurazioni principali, secondarie e di servizio, ad esempio 2.4.11
Il nome è nel formato:
<configurationId>_<version>
Ad esempio,
org.eclipse.sdk_1.1.5.jar
com.ibm.wsa_1.0.1\install.xml
Il jar della configurazione ha la seguente struttura di percorso interno:
install/
configurations/
<configurationId>_<version>/
install.xml
(altri file opzionali) consultare "Conversione delle informazioni di assemblaggio"
(file del "prodotto") consultare "Avvio della piattaforma Eclipse"
Il file .jar contiene un percorso install/configurations/ e un file install.xml; la directory meta-inf/ prodotta dalle utilità jar Java.
Il formato della configurazione install.xml viene definito dalla seguente dichiarazione DTD:
<?xml encoding="US-ASCII"?>
<!ELEMENT configuration (description?, url?, component*)>
<!ATTLIST configuration
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
provider-name CDATA #IMPLIED
application CDATA #IMPLIED
>
<!ELEMENT description (#PCDATA)>
<!ELEMENT url (update*, discovery*)>
<!ELEMENT update EMPTY>
<!ATTLIST update
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT discovery EMPTY>
<!ATTLIST discovery
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT component EMPTY>
<!ATTLIST component
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
allowUpgrade (true | false) "false"
optional (true | false) "false"
>
Di seguito sono riportate le definizioni degli elementi e degli attributi:
-
<configuration> - definisce la configurazione
-
label - etichetta visualizzabile facoltativa (nome)
-
id - identificativo necessario della configurazione (ad esempio org.eclipse.sdk)
-
version - versione necessaria della configurazione (ad esempio 1.0.3)
-
provider-name - etichetta facoltativa di visualizzazione, che identifica l'organizzazione che fornisce questa configurazione
-
application - identificativo opzionale di un'estensione registrato nel punto di estensione di un'applicazione eclipse. Se non specificato, viene automaticamente impostato l'identificativo dell'applicazione standard del workbench Eclipse. Questa è l'applicazione che viene lanciata se la configurazione che la contiene costituisce la "principale" applicazione installata.
-
<description> - breve descrizione della configurazione
-
<url> - URL facoltativo che specifica i siti che contengono aggiornamenti della configurazione
-
<update> - URL cui collegarsi per aggiornare questa configurazione
-
url - URL corrente
-
label - etichetta visualizzabile (nome) del sito indicato
-
<discovery> - URL cui collegarsi per nuovi componenti o nuove configurazioni. In genere un provider utilizza questo elemento per fare riferimento al proprio sito o ai siti dei propri partner che offrono componenti o configurazioni complementari.
La piattaforma Eclipse utilizza questo elemento semplicemente per distribuire nuovi URL ai client.
-
url - URL corrente
-
label - etichetta visualizzabile (nome) del sito indicato
-
<component> - identifica il componente configurato
-
label - etichetta facoltativa visualizzabile (nome) del componente configurato
-
id - identificativo necessario del componente
-
version - versione necessaria del componente
-
allowUpgrade - facoltativo, l'impostazione predefinita è "false". Indica al gestore degli aggiornamenti se la configurazione consente l'aggiornamento del componente ad una nuova versione secondaria dello stesso componente (true) o se invece consente solo gli aggiornamenti di servizio (false).
Nessuna configurazione può prevedere l'aggiornamento di un componente ad una versione superiore. Una tale modifica richiederebbe prima l'aggiornamento della configurazione.
-
optional - facoltativo, l'impostazione predefinita è "false". Indica al gestore degli aggiornamenti se il componente deve essere sempre installato come parte di questa configurazione (false) o può essere escluso (deselezionato) dall'installazione (true).
L'attuale implementazione della piattaforma Eclipse non consente la nidificazione delle configurazioni o la specifica di
regole di componenti più complessi.
Conversione delle informazioni di assemblaggio
Alcuni degli attributi dei manifest di installazione sono stringhe destinate alla visualizzazione attraverso interfacce utenti. Per facilitare la conversione, questi attributi utilizzano la convenzione definita per attributi convertibili di plugin.xml. Le stringhe che hanno come primo carattere "%" vengono considerate come chiavi di identificativi di risorsa (senza il simbolo "%") e ricercate in un file di proprietà. Ad esempio
label="%cfg Eclipse SDK for Linux"
determina la ricerca di risorse nel relativo file di proprietà con la chiave "cfg".
Se non si specifica alcun file di proprietà o non viene rilevata la chiave, sarà utilizzato il valore predefinito della stringa seguito da %key.
I file di proprietà sono denominati install_<locale>.properties utilizzando le convenzioni di denominazione dell'insieme di risorse Java. All'interno del componente e della configurazione .jar, i file vengono posizionati nella stessa directory dei corrispondenti file install.xml.
Quando si accede all'insieme delle risorse, il codice può selezionare l'opportuna variante NL del manifest (implementando un algoritmo di ricerca) e creare un insieme utilizzando
ResourceBundle b;
b = new PropertyResourceBundle(properties.openStream());
In alternativa, il codice può utilizzare il supporto Java per localizzare la corretta variante NL del manifest nel modo seguente:
ResourceBundle b;
ClassLoader l;
l = new URLClassLoader(new URL[] {<targetDirectoryURL>}, null);
b = ResourceBundle.getBundle("install",Locale.getDefault(),l);
L'insieme di risorse così ottenuto può essere utilizzato in IPluginDescriptor.getResourceString(String,ResourceBundle)
per restituire la corretta stringa convertita per l'attributo del manifest.
Considerazioni sulla sicurezza
I file .jar dei componenti e delle configurazioni possono essere firmati utilizzando le utilità di protezione Java standard, come ad esempio jarsigner. All'avvio, il gestore degli aggiornamenti verificherà che il file .jar sia fornito da un provider affidabile e che il contenuto del file non abbia subito modifiche dopo la firma. All'utente viene data l'opzione di accettare file .jar di provider non affidabili. I file che sono stati modificati dopo la firma vengono automaticamente respinti durante la fase di avvio della piattaforma Eclipse.
Assemblaggio NL
I file NL vengono assemblati in sottodirectory diverse per ogni impostazione internazionale supportata.
Le sottodirectory possono essere definite nella corrente directory di plug-in (ossia "ancorata" al plug-in) oppure possono essere assemblate in diversi frammenti di plug-in. In entrambi i casi, durante la fase di avvio della piattaforma Eclipse la directory del plug-in di base e i file dell'appropriata impostazione internazionale vengono uniti in una struttura di accesso logico unico, per quanto fisicamente assemblati.
L'assemblaggio di file NL come frammenti di plug-in determina una struttura di installazione leggermente più complessa. Il principale vantaggio consiste nella possibilità di aggiungere il contenuto del file NL al plug-in di base in un momento successivo; in altre parole, non è necessario effettuare il trasferimento contemporaneamente. Un altro vantaggio consiste nella possibilità di modificare i frammenti in modo indipendente dal plug-in di base, a parte gli aggiornamenti di servizio.
Di seguito sono riportate queste due diverse strutture di installazione per l'assemblaggio NL.
Assemblaggio NL "inline" con plug-in
install/
plugins/
<pluginId>_<version>/
(file "plug-in")
nl/
<locale>/
(file NL)
Ad esempio:
install/
plugins/
my.funky.plugin_1.0.1/
plugin.xml
my.jar ... contenente classi e risorse predefinite
nl/
de_DE/
my.jar ... contenente il delta convertito
Assemblaggio NL come frammento di plug-in
install/
fragments/
<fragmentId>_<version>/
fragment.xml
nl/
<locale>/
(file NL)
Ad esempio:
install/
fragments/
my.funky.plugin_german_1.0.1/
fragment.xml
nl/
de_DE/
my.jar ... contenente il delta convertito
I nomi di directory delle impostazioni internazionali, rispettano le convenzioni standard Java di denominazione delle impostazioni internazionali.
Si noti che in genere il contenuto del plug-in di base deve includere le risorse NL predefinite, in modo che la funzione operi in modo accettabile in caso di assenza dell'opportuna struttura di impostazione internazionale; in altre parole, è meglio mostrare la stringa predefinita rispetto agli identificativi di risorsa nell'interfaccia utente.
I meccanismi di run-time, il formato fragment.xml e le API per la gestione delle directory e dei frammenti NL sono descritti in altre sezioni della documentazione relative alla piattaforma Eclipse.
Assemblaggio del supporto specifico per la destinazione
I file specifici per il sistema operativo o per i sistemi a finestre sono assemblati in diverse sottodirectory per ciascuna destinazione supportata. Le sottodirectory possono essere definite nella corrente directory di plug-in (ossia "ancorata" al plug-in) oppure possono essere assemblate in diversi frammenti di plug-in. In entrambi i casi, durante la fase di avvio della piattaforma Eclipse la directory del plug-in di base e i file dell'appropriata destinazione vengono uniti in una struttura di accesso logico unico, per quanto fisicamente assemblati.
L'assemblaggio di file di destinazione come frammenti di plug-in determina una struttura di installazione leggermente più complessa. Il principale vantaggio consiste nella possibilità di aggiungere il contenuto del file di destinazione al plug-in di base in un momento successivo; in altre parole, non è necessario effettuare il trasferimento contemporaneamente. Un altro vantaggio consiste nella possibilità di modificare i frammenti in modo indipendente dal plug-in di base, a parte gli aggiornamenti di servizio.
Di seguito sono riportate queste due diverse strutture di installazione per l'assemblaggio di file di destinazione.
Assemblaggio specifico di destinazione "ancorata" al plug-in
install/
plugins/
<pluginId>_<version>/
(file "plug-in")
os/
<os-name>/
(file OS)
ws/
<windowing-system-name>/
(file specifici dei sistemi a finestre)
Ad esempio:
install/
plugins/
my.funky.plugin_1.0.1/
plugin.xml
my.jar
os/
solaris/
libfoo.so
ws/
motif/
my.jar
Assemblaggio del supporto specifico per la destinazione come frammento di plug-in
install/
fragments/
<fragmentId>_<version>/
fragment.xml
os/
<os-name>/
(file OS)
ws/
<windowing-system-name>/
(file specifici dei sistemi a finestre)
Ad esempio:
install/
fragments/
my.funky.plugin_solaris_1.0.1/
fragment.xml
os/
solaris/
libfoo.so
ws/
motif/
my.jar
Gli identificativi di destinazione utilizzati per i nomi delle directory sono definiti dalla piattaforma Eclipse (consultare Javadoc org.eclipse.core.boot.BootLoader).
I meccanismi di run-time, il formato fragment.xml e le API per la gestione delle directory e dei frammenti di destinazione sono descritti in altre sezioni della documentazione relative alla piattaforma Eclipse.
Assemblaggio file di supporto
File di supporto addizionali possono essere assemblati direttamente nelle directory di plug-in oppure come frammenti. Questi file possono includere dimostrazioni, esempi, documentazione di riferimento per sviluppatori, tipi di test e altre informazioni che non forniscono direttamente la funzione base dell'utente. In genere la piattaforma non specifica la posizione e l'utilizzo di questi file. Tuttavia, quando assemblati come frammenti, la piattaforma fornisce un supporto per l'accesso come singola struttura logica allo spazio comune di plug-in e frammenti. Questo consente al plug-in di base di contenere solo il supporto per utente primario ed inviare le ulteriori informazioni solo se i frammenti necessari sono contemporaneamente presenti.
Struttura di installazione
Differenze tra l'installazione completa e l'installazione di riferimento
Eclipse supporta due tipi di installazione:
-
Installazione completa. Struttura del file system derivante dall'esecuzione del processo di installazione. I file vengono posizionati nei file system così come previsto dalla piattaforma Eclipse per l'esecuzione diretta.
La funzione Eclipse può essere eseguita direttamente solo con l'installazione completa.
-
Installazione di riferimento. Struttura di file esistente in una posizione di aggiornamento Eclipse utilizzata per selezionare configurazioni e componenti installabili.
Mapping di file system: installazione completa
L'installazione completa è considerata il risultato del processo di installazione, precisando che si tratta del risultato dell'installazione "tradizionale" o dell'azione del gestore degli aggiornamenti. La piattaforma Eclipse può essere eseguita direttamente dopo una installazione completa.
Questo tipo di installazione contiene la seguente struttura di file:
<installation root>/
install/
install.properties
components/
<componentId>_<version>/
install.xml
install_<locale>.properties (facoltativo)
configurations/
<configurationId>_<version>/
install.xml
install_<locale>.properties (facoltativo)
(altri file del "prodotto") (facoltativo)
plugins/
<pluginId>_<version>/
plugin.xml
(altri file di plug-in)
fragments/
<fragmentId>_<fragmentVersion>/
fragment.xml
(altri file di frammento, tra cui plugin.xml)
La definizione delle directory e dei file avviene come descritto in precedenza per i file .jar delle configurazioni e dei componenti.
Il file install.properties contiene proprietà configurabili di avvio. Esso riflette l'impostazione di avvio corrente per la piattaforma e l'applicazione installata.
Il corretto modo di utilizzo viene descritto nella sezione "Avvio della piattaforma Eclipse". Questo file viene inizialmente installato come parte di una nuova installazione. In seguito viene modificato dal gestore degli aggiornamenti ogni volta che viene modificata l'installazione di Eclipse.
Se il file viene modificato diversamente in modo da risultare incompatibile con l'installazione originaria, viene ripristinato l'ultimo stato valido.
Il formato del file è quello di un file di proprietà Java e contiene i seguenti elementi:
application=<applicationId>
application.configuration=<configurationId>_<version>
runtime=<pluginId>_<version>
Ad esempio
application=
application.configuration=com.ibm.wsa_1.0.3
runtime=org.eclipse.core.boot_1.1.4
Le definizioni di proprietà sono:
-
application - l'identificativo dell'applicazione da eseguire. Si tratta di un identificativo di un'estensione registrato nel punto di estensione the org.eclipse.core.runtime.applications. Questo è il codice dell'applicazione corrente avviata dalla piattaforma. Se non specificata, per impostazione predefinita, viene avviato il workbench fornito con Eclipse.
-
application.configuration - nome della directory (nella struttura install/configurations/) della configurazione corrispondente a questa applicazione. Essa può contenere file di avvio propri dell'applicazione (ad esempio, apertura immagine), che consentono all'utilità di avvio di selezionare la corretta versione di questi file da utilizzare all'avvio.
-
runtime - nome della directory (nella struttura plugins/) in cui si è posizionato il file boot.Jar della piattaforma Eclipse. Esso consente all'utilità di avvio di selezionare la corretta versione della piattaforma da eseguire. Il gestore degli aggiornamenti imposta questo valore dopo ogni aggiornamento della piattaforma. Se la piattaforma viene aggiornata in seguito ad un'installazione tradizionale, è necessario impostare questa proprietà in modo corretto.
I file delle proprietà di installazione vengono creati dall'utilità di installazione iniziale.
Una volta installati, le proprietà dell'applicazione e di run-time possono essere aggiornate. Tuttavia è possibile modificare solo il suffisso di versione della configurazione dell'applicazione, escluso l'identificativo "principale" della configurazione.
Nota: come indicato in questa sezione, l'installazione iniziale di un prodotto basato su Eclipse deve prevedere l'installazione anche del file install.properties, che riflette le corrette impostazioni di avvio, altrimenti non sarà possibile eseguire il prodotto.
File dell'area di lavoro
Nella configurazione utente tipica, <installation root> contiene anche i file dell'area di lavoro dell'utente. Questi vengono creati al momento dell'avvio della piattaforma. In una configurazione che prevede più aree di lavoro, la piattaforma viene avviata con una directory dell'area di lavoro specificata esplicitamente. Tutti i file creati come parte dell'esecuzione della piattaforma vengono scritti nelle directory dell'area di lavoro.
In uno scenario che prevede più aree di lavoro, l'utente deve assicurarsi che le istanze del gestore degli aggiornamenti siano eseguite una per volta. Questa configurazione assomiglia ad un'installazione condivisa tra più utenti; tuttavia solo l'installazione condivisa "amministratore" assicura che i singoli utenti abbiano un accesso di sola lettura alla directory principale di installazione.
Mapping di file system: installazione di riferimento
La struttura del file system nell'installazione di riferimento è simile a quella dell'installazione completa. Essa contiene i seguenti elementi:
<installation root>/
install/
components/
install.index (facoltativo)
<componentId>_<version>/
install.xml
install_<locale>.properties (facoltativo)
<componentId>_<version>.jar
configurations/
install.index (facoltativo)
<configurationId>_<version>/
install.xml
install_<locale>.properties (facoltativo)
<configurationId>_<version>.jar
L'installazione di riferimento può essere realizzata semplicemente, decomprimendo parzialmente il manifest di installazione (e qualsiasi altro insieme di risorse di installazione) dal file .jar della configurazione o del componente e poi copiando l'intero file Jar nella struttura di directory così ottenuta (come peer di install.xml). L'esposizione di install.xml consente al gestore degli aggiornamenti di determinare cosa è disponibile in un determinato sito. Una volta selezionato, il corrispondente file .jar viene scaricato ed installato.
Quando si accede al sito per l'installazione di riferimento mediante un protocollo piuttosto che mediante l'I/O file diretto, il sito deve contenere anche l'install.index facoltativo, nelle directory relative ai componenti o alle configurazioni. Questo file costituisce una semplice directory di "sommario", che contiene i nomi delle sottodirectory presenti su linee separate.
Ad esempio:
<installation root>/
install/
components/
install.index
org.eclipse.platform_1.0.1/
org.eclipse.jdt_2.9.5/
org.eclipse.pde_1.0.4/
Il file install.index contiene:
org.eclipse.platform_1.0.1
org.eclipse.jdt_2.9.5
org.eclipse.pde_1.0.4
Il file install.index non è necessario quando si accede al file attraverso l'i/o file diretto (come "file" URL). Si noti, tuttavia, che se il file è presente viene utilizzato anche in caso di accesso mediante i/o file diretto. In questo modo, il file può essere utilizzato, dall'amministratore del sito per controllare le configurazioni e i componenti esposti. Solitamente ciò è utile quando i componenti contenuti nelle configurazioni non possono essere scaricati ed installati come elementi separati (gestiti solo attraverso alcune configurazione).
In questo caso le configurazioni verranno esposte direttamente, ma non anche i componenti. I componenti potranno essere localizzati solo attraverso le configurazioni esposte.
Avvio della piattaforma Eclipse
Prima di passare all'analisi delle considerazioni sugli aggiornamenti, è importante comprendere la procedura di avvio della piattaforma Eclipse descritta di seguito:
-
La directory principale di installazione contiene il comando di avvio del "prodotto".
Può trattarsi di un semplice "script" di comando (.bat), oppure la funzione di questo script può essere eseguita da una semplice (.exe).
In entrambi i casi, il comando di avvio esegue tre operazioni
-
Legge il file install.properties (consultare la precedente descrizione sul contenuto di tale file).
Rileva l'immagine di apertura nella directory di configurazione dell'applicazione (proprietà di configurazione dell'applicazione) e la visualizza.
-
Seleziona la JVM da eseguire e la avvia, attraverso il comando java oppure caricando direttamente le JVM eseguibili. I criteri di selezione jre includono la posizione di jre passate esplicitamente, la posizione relativa all'utilità di avvio o l'impostazione della variabile di ambiente, condividendo jre comuni nel sistema.
-
Carica la classe Main da startup.jar ed esegue il relativo metodo main(...).
-
Questa classe viene passata alla posizione degli eseguibili della piattaforma Eclipse (proprietà run-time) e l'identificativo di un'applicazione viene passato alla piattaforma da eseguire (proprietà dell'applicazione; il workbench è l'applicazione predefinita fornita da Eclipse). La classe Main localizza il file boot.jar della piattaforma e carica BootLoader da esso. Questa classe comanda a BootLoader di passare l'identificativo dell'applicazione come un argomento, insieme ad altri argomenti di avvio.
-
BootLoader avvia il run-time principale della piattaforma. Questo determina il caricamento e la risoluzione del registro del plug-in (configurando i plug-in che saranno scelti per l'esecuzione).
-
BootLoader ricerca il nome dell'applicazione (passato come argomento) nel registro di plug-in e, se lo trova, attiva il plug-in dell'applicazione e gli trasferisce il controllo.
-
L'applicazione avviata, ad esempio il workbench, attiva e chiama gli altri plug-in necessari.
Nota: l'utilità di avvio predefinita fornita con l'attuale versione della piattaforma Eclipse non elabora il file install.properties
(come descritto nelle precedenti fasi 1 e 2). Essa localizza la schermata di apertura predefinita e il run-time della piattaforma relativa ad essa.
Considerazioni sugli aggiornamenti
Aggiornamento di componenti estranei alla piattaforma
I componenti estranei alla piattaforma prevedono dei plug-in che vengono eseguiti sulla piattaforma.
Il gestore degli aggiornamenti si limita a installare le directory e i file dei plug-in indicati. Questi vengono rilevati ed elaborati al successivo avvio della piattaforma.
Il gestore degli aggiornamenti non modifica mai una struttura di directory i un plug-in esistente,
ma si limita a installare una versione di un plug-in, che prima non esisteva.
Se la directory di plug-in già esiste, magari inclusa in una versione di qualche altro componente, non viene installata nuovamente. Il gestore degli aggiornamenti non verifica se il contenuto della directory esistente corrisponde a quello del componente .jar. Di conseguenza, l'identificativo della versione di plug-in deve essere correttamente riprodotto nel nome della directory del plug-in.
Aggiornamento della piattaforma
La versione attuale della piattaforma Eclipse non consente l'aggiornamento automatico attraverso il gestore degli aggiornamenti. Gli aggiornamenti della piattaforma devono essere realizzati servendosi dei tradizionali meccanismi di installazione.
Aggiornamento dei file JRE
La versione attuale della piattaforma Eclipse non consente l'aggiornamento automatico attraverso il gestore degli aggiornamenti. Gli aggiornamenti dei file JRE devono essere realizzati servendosi dei tradizionali meccanismi di installazione.
Aggiornamento dei file di prodotto
L'installazione di un pacchetto generalmente prevede un insieme di diversi file che vengono posizionati nella directory di avvio del prodotto. L'insieme include file Leggimi, immagini iniziali, copie dei contratti di licenza, note di rilascio e altro. Questi file devono essere assemblati come parte dei jar dei componenti o delle configurazioni, cioè come file ulteriori all'interno di una determinata directory di componente o di configurazione (come peer di install.xml). Sono supportati sia i singoli file che le sottodirectory. In questo modo tali file vengono assemblati, trasmessi e installati come parte del file jar del componente o della configurazione di versione.
Ad esempio, un file jar del componente può contenere:
install/
components/
com.xyx.etools_1.3.5/
install.xml
splash.bmp
readme.txt
license.txt
notes/
jspedit.txt
debug.txt
Aggiornamento del supporto di avvio
La versione attuale della piattaforma Eclipse non consente l'aggiornamento dell'utilità di avvio (.exe, startup.jar) attraverso il gestore degli aggiornamenti. Tale aggiornamento deve essere realizzato utilizzando i tradizionali meccanismi di installazione.
Ripristino in seguito all'interruzione di un aggiornamento
Vi sono due ipotesi da considerare:
-
Interruzioni controllate - si tratta di errori relativi ad accessi, download, decompressioni, rilevati dal gestore degli aggiornamenti, che è in grado di risolvere tali malfunzionamenti.
-
Interruzioni "non controllate" - si tratta di interruzione improvvise (come ad esempio un calo di tensione) durante il processo di aggiornamento, che si verificano prima che il gestore degli aggiornamenti termini le proprie operazioni. Questi vengono rilevati all'avvio della piattaforma. La struttura di installazione viene confrontata con la versione più recente, in modo da poter rilevare ed eliminare tutte le modifiche parziali.
Ripristino in seguito a un aggiornamento non valido
Il gestore degli aggiornamenti memorizza una descrizione dello stato attuale della configurazione di installazione. Questa descrizione prevede un elenco delle configurazioni e dei componenti "attivi": l'attuale struttura di installazione, infatti, potrebbe contenere altre versioni delle configurazioni e dei componenti che sono in realtà nascoste a causa di aggiornamenti successivi.
Dopo un aggiornamento, il gestore degli aggiornamenti memorizza queste informazioni all'arresto della piattaforma; le informazioni sullo stato vengono copiate e lo stato precedente viene salvato, così da realizzare una sequenza cronologica degli aggiornamenti. È possibile impostare l'opzione che stabilisce il numero di stati precedenti che il gestore degli aggiornamenti deve memorizzare. Le precedenti versioni di stato, con i componenti e le configurazioni corrispondenti, vengono regolarmente inserite nel processo di pulitura (eliminazione) del gestore degli aggiornamenti.
Le copie appartenenti ai livelli precedenti consentono il ripristino in seguito ad aggiornamenti "non validi", cioè nei casi in cui il gestore degli aggiornamenti ha correttamente scaricato ed applicato una modifica, che tuttavia causa dei problemi.
Pulitura dell'installazione
Il gestore degli aggiornamenti provvede regolarmente ad eliminare il contenuto della struttura di installazione.
Vengono conservati solo i riferimenti alle configurazioni e ai componenti contenuti nelle versioni di stato degli aggiornamenti più recenti; l'utente può modificare l'opzione che definisce il numero degli stati da conservare. La pulitura fa parte delle operazioni del gestore degli aggiornamenti e non richiede un'esplicita attivazione.
Funzione Eclipse non gestita
Oltre all'installazione formale dei componenti e delle configurazioni, la piattaforma Eclipse consente di posizionare plug-in e frammenti di plug-in direttamente nella struttura di installazione, senza una corrispondente descrizione da parte dei manifest di installazione. Questi plug-in vengono rilevati all'avvio, ma non possono essere modificati o rimossi utilizzando le funzioni del gestore degli aggiornamenti; per questo motivo si definiscono "non gestiti". Questo supporto è stato progettato proprio per gli scenari di sviluppo dei plug-in, allo scopo di evitare l'eccessivo sviluppo di assemblaggio o di installazione. L'utilità di installazione tradizionale potrebbe non essere in grado di installare plug-in e frammenti di plug-in non gestiti.
Considerazioni sull'installazione
Occorre distinguere l'installazione di una nuova base della piattaforma Eclipse (file .jre, piattaforma e applicazione principale) dall'installazione (unione) di nuovi componenti in una base già esistente.
Nuova installazione
Attualmente, l'installazione di una nuova piattaforma deve essere realizzata utilizzando una tecnologia di installazione tradizionale, come Windows MSI Installer, RPM, InstallShield
o un semplice meccanismo di archiviazione, quale un file .zip. L'utilità di installazione deve fare in modo che, al termine delle operazioni, la struttura dei file rispecchi le specifiche del presente documento.
L'utilità di installazione deve:
-
definire una nuova struttura di installazione per la piattaforma Eclipse
-
registrare eventualmente la nuova struttura della piattaforma con il relativo registro specifico per il sistema operativo
-
installare una copia del JRE (Java Runtime Environment) o assicurare la corretta configurazione di un JRE da utilizzare con la piattaforma Eclipse
-
installare la piattaforma Eclipse (almeno i componenti org.eclipse.core e org.eclipse.ui)
-
installare la configurazione dell'applicazione principale. Di solito, questo implica la configurazione dell'intera applicazione, dei componenti necessari e dei rispettivi plug-in o frammenti di plug-in. Tuttavia è anche possibile installare solo una configurazione "segnaposto" per l'applicazione, che specifichi una posizione di aggiornamento contenete la funzione dell'attuale applicazione; in questo caso, l'utente deve avviare manualmente lo scaricamento/aggiornamento dopo l'avvio della piattaforma Eclipse.
-
installare il file iniziale install.properties come descritto in precedenza (impostazioni di configurazione di avvio).
Analogamente, per rimuovere l'applicazione principale e la relativa struttura della piattaforma Eclipse, è necessaria un utilità di disinstallazione tradizionale. Questa utilità ha il compito di annullare tutte le azioni compiute dall'utilità di installazione. Tuttavia, dal momento che il contenuto della struttura di installazione Eclipse può essere modificato mediante l'utilizzo del gestore degli aggiornamenti, l'utilità di disinstallazione tradizionale potrebbe non essere in grado di rilevare i file originariamente installati. Alcuni file potrebbero non essere più presenti (perché rimossi dal gestore degli aggiornamenti) e la struttura di installazione potrebbe contenere file ulteriori che non erano stati installati all'origine (modifiche aggiunte). Quindi l'utilità di disinstallazione tradizionale, che si attiene al log di installazione, di solito non riesce a rimuovere completamente l'applicazione.
Per poter eliminare anche le modifiche apportate dal gestore degli aggiornamenti, l'utilità di disinstallazione deve eliminare tutti i file presenti nelle seguenti directory di installazione Eclipse:
-
install/ - contiene informazioni sulla configurazione dell'installazione e non contiene dati dell'utente
-
plugins/ - contiene plug-in, eseguibili e non contiene dati dell'utente
-
fragments/ - contiene frammenti di plug-in, eseguibili e non contiene dati dell'utente
Le altre directory che risiedono nella struttura di installazione potrebbero contenere dati dell'utente e pertanto non devono essere rimosse.
Installazione unita
Dopo l'installazione della piattaforma Eclipse (consultare la sezione precedente), è possibile aggiungere componenti e configurazioni alla piattaforma utilizzando il gestore degli aggiornamenti Eclipse o un'utilità di installazione tradizionale. In questo caso, l'utilità di installazione deve fare in modo che, al termine delle operazioni, la struttura dei file rispecchi le specifiche del presente documento.
L'utilità di installazione deve:
-
rilevare in modo automatico la posizione della piattaforma Eclipse installata (nel caso dei sistemi che supportano un meccanismo di registrazione) oppure richiederla all'utente
-
installare i componenti e le configurazioni opportune, con i relativi plug-in e frammenti di plug-in
-
eventualmente salvare un file che riporti la struttura dell'installazione unita, da utilizzare durante la disinstallazione tradizionale.
L'impiego dell'utilità di disinstallazione tradizionale, in caso di installazione unita, richiede particolare attenzione. Di solito, le utilità di disinstallazione non dovrebbero mai rimuovere i file di programma installati. Questo perché i file originariamente installati potrebbero non essere più presenti oppure potrebbero essere stati aggiornati, in seguito al normale funzionamento di Eclipse. Di conseguenza, un tentativo di rimozione diretta di questi file potrebbe, nella migliore ipotesi, non avere alcun effetto; nella peggiore delle ipotesi, però, potrebbe determinare la rimozione di una parte del supporto installato utile al normale funzionamento, provocando errori imprevedibili al successivo avvio dell'applicazione. Le conseguenze sono ancora più gravi se i componenti o i plug-in sono condivisi. È consigliabile procedere all'eliminazione diretta dei file di una configurazione o di un componente solo nel caso in cui si è certi che questi non sono stati modificati e non sono condivisi.
Particolare attenzione è richiesta nel caso si utilizzino tecnologie di installazione che non consentono di controllare nel modo sopra descritto il processo di disinstallazione. RPM di Linux costituisce un esempio di queste tecnologie. L'impiego di queste utilità di installazione è sconsigliato nei casi di installazione unita e comunque non deve mai essere eseguito il relativo processo di disinstallazione.
Un'utilità di disinstallazione tradizionale può realizzare una rimozione sicura della funzione installata, utilizzando i file di struttura dell'installazione unita. Si tratta di file installati facoltativamente come parte dell'installazione unita e rappresentano un punto di riferimento per i relativi componenti e le relative configurazioni. La piattaforma Eclipse rileva la rimozione dei file di struttura durante la fase di avvio e procede così alla rimozione sicura dei componenti e delle configurazioni elencate.
Nota: a differenza dei file dei componenti e delle configurazioni, i file di struttura non sono soggetti a modifiche da parte del gestore degli aggiornamenti. Pertanto l'utilità di disinstallazione tradizionale sicuramente rileverà questi file.
Una volta installati, i file di struttura vengono posizionati nella directory install/info/ della directory principale di installazione Eclipse (peer delle directory install/configurations e install/components. I file utilizzano le seguenti convenzioni di denominazione:
<merged-installation-identifier>.install
La piattaforma Eclipse non specifica il formato dell'identificativo, che in ogni caso non viene interpretato. Per ridurre il rischio di conflitti di denominazione, si raccomanda di utilizzare per l'identificativo convenzioni di denominazioni basate sul nome del dominio internet del provider (ad esempio com.xyz.toolpack.install).
Di seguito viene riportato il contenuto del file di struttura, che utilizza il formato del file di proprietà Java:
configurations=[<configId>_<version> [, <configId>_<version>]*
]
components=[<compId>_<version> [,<compId>_<version>]*
]
dove
[] elemento facoltativo
* gruppo di ripetizione
Entrambe le proprietà per esteso sono espresse da una serie di identificativi con il corrispondente suffisso di versione, separati da una virgola.
Registrazione specifica per la piattaforma
Nota: questa sezione descrive una procedura consigliata, che tuttavia non è indispensabile alla corretta esecuzione della piattaforma Eclipse.
Per i prodotti Eclipse si consiglia di utilizzare un meccanismo di registrazione del sistema operativo che conservi una traccia di tutte le posizioni di installazione delle piattaforme Eclipse. In questo modo è più semplice individuare l'installazione della piattaforma cui unire i nuovi componenti o decidere di realizzare una nuova installazione di piattaforma. Se non viene utilizzato questo meccanismo, all'utente verrà richiesto di specificare le directory di installazione Eclipse.
Di solito l'utilità di installazione consente di realizzare una nuova installazione o di unire i componenti a una precedente installazione. Inoltre, mediante una nuova installazione, è possibile aggiornare le strutture di registrazione.
Per questo scopo, in Windows, viene utilizzato il registro di Windows. Di seguito viene suggerita una struttura chiave del registro per identificare le directory di installazione della piattaforma Eclipse:
eclipse.org/
platforms/
<product name>
La chiave <product name> identifica il provider e/o l'applicazione principale creata dalla nuova installazione della piattaforma Eclipse.
L'intera chiave esegue il mapping dei seguenti attributi
label = etichetta visualizzabile relativa alla chiave <product name>, localizzata nel momento della creazione.
directory = <absolute path>
Considerazioni sullo sviluppo
Indipendenza della posizione di installazione
L'API di Eclipse consente attraverso l'esecuzione di un plug-in di ottenere un riferimento alla propria directory di installazione. Ciò è possibile mediante la chiamata a IPluginDescriptor.getInstallURL(), che restituisce java.net.URL. L'esecuzione dei plug-in consente l'accesso a tutte le risorse relative a questo URL. Il supporto del protocollo URL gestisce il reindirizzamento necessario alla directory del plug-in locale, alla cache del plug-in, al CD (installazione minima) o al server. Il metodo più frequente di accesso di un plug-in alle proprie risorse consiste nell'apertura di un flusso di input nell'URL e nella successiva lettura del contenuto della risorsa. Dal momento che la posizione di installazione viene considerata di sola lettura, il plug-in di esecuzione non deve tentare operazioni di scrittura utilizzando l'URL restituito.
Eseguibili nativi
Le librerie Java native utilizzate dai plug-in Eclipse non richiedono nessuna particolare operazione di gestione. Esse vengono installate come parte delle strutture di directory del plug-in e caricate dal caricatore di classe della piattaforma (jdk 1.2+).
I componenti nativi del sistema operativo, come ActiveX, richiedono un'installazione personalizzata non realizzabile mediante il gestore degli aggiornamenti Eclipse. L'utilità di installazione personalizzata registra i componenti con gli appropriati servizi del sistema operativo e aggiorna i percorsi di ricerca standard. La piattaforma Eclipse non prevede alcun controllo automatico per i componenti nativi necessari. Viene richiesto il codice del plug-in per implementare la necessaria logica di controllo/ripristino. L'utilità di installazione personalizzata può creare un plug-in "indicatore" della presenza di componenti nativi, in modo da consentire ad altri plug-in di specificare la dipendenza. Tuttavia, questo approccio non è infallibile e non può garantire in modo assoluto la soddisfazione della dipendenza degli elementi nativi.
Supporto per versioni contemporanee di plug-in
La piattaforma Eclipse consente l'installazione contemporanea di più versioni di uno stesso plug-in. In questo modo possono aversi ipotesi in cui un utente installa due prodotti Eclipse che contengono diverse versioni dello stesso plug-in. Entrambe le versioni possono essere installate nella stessa directory principale del programma. In base alle regole di configurazione, di cui si dirà in seguito, la piattaforma di solito utilizza durante l'esecuzione la versione più recente del plug-in. Tuttavia se l'utente disinstalla uno dei prodotti, la struttura di installazione dell'altro prodotto resta invariata e quindi continuerà a contenere la corretta versione del plug-in installato con il prodotto.
La piattaforma Eclipse consente la configurazione e l'esecuzione contemporanea di più versioni dello stesso plug-in. Questa funzione è particolarmente utile ai plug-in che contengono librerie di run-time condivise. Se un utente del run-time condiviso volesse specificare una dipendenza su una determinata versione del plug-in,
tale plug-in dovrebbe dichiarare solo le proprie librerie di run-time (nella sezione <runtime> di plugin.xml), senza dover dichiarare alcun ulteriore elemento alla piattaforma; in particolare non è necessaria la dichiarazione dei punti di estensione e/o l'indicazione delle estensioni.
A questo scopo, la piattaforma Eclipse definisce schemi per l'identificazione di plug-in, convenzioni per la denominazione di directory di plug-in nel file system e un insieme di regole per la configurazione e l'esecuzione dei plug-in localizzati durante l'avvio della piattaforma.
I plug-in vengono identificati da una combinazione di una stringa strutturata come un nome di pacchetto Java e un identificativo di versione multidecimale. L'identificativo di versione consiste in un componente principale che indica una generazione incompatibile e un componente minore che indica un'evoluzione compatibile del plug-in.
-
id - identificativo univoco del plug-in. Si tratta di una stringa strutturata come un nome di pacchetto Java. Gli schemi di identificazione impediscono collisioni di denominazione, mediante una semplice convenzione di denominazione gerarchica, basata sui nomi dei domini internet registrati dai singoli produttori dei plug-in. Due esempi di identificativi univoci corretti sono org.eclipse.ui ed edu.xyz.tools.
-
version - un identificativo multidecimale, che segue la definizione descritta per la classe PliginVersionIdentifier (major.minor.service)
Dal momento che più versioni di un plug-in possono essere installate nella stessa struttura di file, le directory dei singoli plug-in devono essere individuate in modo univoco per evitare un involontario sovrapporsi di versioni. È consigliabile denominare la directory del plug-in combinando l'identificativo univoco del plug-in con l'identificativo della versione. Utilizzare il carattere di sottolineatura per separare la stringa della versione dalla stringa del nome.
Di seguito vengono riportati gli esempi dei nomi di directory relativi ai corrispondenti plug-in.
Plug-in |
Versione |
Nome di directory consigliato |
org.eclipse.ui |
1.3.17 |
org.eclipse.ui_1.3.17 |
edu.xyz.tools |
1.0.1 |
edu.xyz.tools_1.0.1 |
La piattaforma prevede un'API per la composizione degli identificativi di versione
-
IPluginDescriptor.getVersionIdentifier() - restituisce l'identificativo di versione di un determinato plug-in
-
implementazione della classe di PluginVersionIdentifier. I metodi di questa classe consentono l'accesso al componente principale e a quello minore dell'identificativo. Questi metodi inoltre implementano la corrispondenza della compatibilità e dell'eguaglianza delle versioni.
Vi è un'ultima considerazione da esaminare relativa ai plug-in che consentono l'esecuzione contemporanea e scrivono lo stato del plug-in o i dati di lavoro; fare riferimento a Plugin.getPluginStateLocation()
e IProject.getPluginWorkingLocation(IPluginDescriptor). Oltre alla migrazione di versione (consultare la sezione seguente), i plug-in provvedono anche alla gestione dell'accesso contemporaneo da più versioni in esecuzione dello stesso plug-in in qualsiasi risorsa condivisa di plug-in. Essi devono utilizzare le funzioni API di accesso al file selezionato per coordinare gli accessi contemporanei.
Migrazione di versione
A causa della natura dinamica della configurazione delle piattaforme, le implementazioni dei plug-in devono occuparsi delle conseguenze della migrazione che può verificarsi durante l'esecuzione. A differenza dei prodotti tradizionali, le soluzioni Eclipse non entrano in azione se non dopo l'avvio della piattaforma.
La piattaforma prevede delle funzioni di base, che possono essere utilizzate dal plug-in per gestire le singole ipotesi di migrazione; tuttavia, la responsabilità del corretto utilizzo di queste funzioni è principalmente dello sviluppatore di plug-in.
Durante l'esecuzione dei plug-in, essi possono scrivere informazioni relative al plug-in in diverse posizioni di lavoro. Utilizzando le seguenti chiamate API si ottengono i riferimenti alle posizioni di lavoro
-
Plugin.getPluginStateLocation() - restituisce la posizione relativa al plug-in dello stato di lavoro dell'intera piattaforma
-
IProject.getPluginWorkingLocation(IPluginDescriptor) - restituisce la posizione di lavoro del plug-in all'interno del progetto specificato
Ogni plug-in deve gestire la migrazione dei propri dati di lavoro.
Vi sono due ipotesi da considerare:
-
migrazione nelle versioni successive - è stata configurata una nuova versione di un plug-in ed è necessaria la migrazione dei dati scritti in una precedente versione. Ciò si basa sul presupposto che la versione n+1 di un plug-in è in grado di leggere i dati scritti dalla versione n dello stesso plug-in.
-
migrazione nelle versioni precedenti - è stata rimossa la versione di un plug-in configurata in una recente chiamata della piattaforma e viene configurata una precedente versione dello stesso plug-in (la versione più recente nasconde la versione precedente). Si tratta di un'ipotesi più problematica, perché non sempre la versione n di un plug-in può leggere dati scritti dalla versione n+1 dello stesso plug-in.
Lo scenario della migrazione nelle versioni successive prevede che la nuova versione del plug-in rilevi, legga, converta e riscriva i dati scritti dalla versione precedente. Queste operazioni possono essere compiute al primo avvio della nuova versione del plug-in (Plugin.startup()) oppure durante l'accesso alle aree di lavoro. In genere, il primo approccio è più utile alla migrazione dei dati di stato del plug-in e il secondo alla migrazione dei dati di progetto.
La migrazione nelle versioni precedenti richiede alcune operazioni ulteriori da parte dello sviluppatore di plug-in. In pratica, la versione n+1 del plug-in deve scrivere i dati in modo che la versione n possa riuscire a rilevarli. Esistono diverse tecniche che i plug-in possono utilizzare a questo scopo.
-
Rilevare formati di dati incompatibili e gestirli con un impatto leggero (la rilevazione dei formati avviene attraverso i dati che indicano la versione oppure in seguito alla ricezione di un errore di dati durante la lettura).
Se non è possibile leggere i dati del plug-in, convertirli al loro stato iniziale, come se non fosse stata rilevata alcuna versione precedente. Il lato negativo di questo approccio consiste nella perdita di dati, quali le impostazioni del plug-in.
-
La versione n+1 scrive tutte le informazioni di base utilizzando il formato n e crea file separati (non riconosciuti da n) per le informazioni estese. La versione n+1 deve accettare i file base e i file di estensione non devono essere sincronizzati (migrazione di n+1 in n ed una successiva migrazione inversa in n+1)
-
Utilizzare il formato di serializzazione con auto descrizione che identifica il contenuto base e le estensioni delle versioni. Le estensioni possono supportare ulteriori qualificatori (ad esempio "ignore if not understood", "must understand" e così via). La versione n di un plug-in può leggere i dati scritti dalla versione n+1 (qualsiasi regola di qualificatore).
Se la versione n aggiorna i dati di base, dovrà riscrivere il file con le corrette estensioni n+1. Le estensioni qualificate come "must understand" non devono essere riscritte. La versione n+1 deve accettare il contenuto base e le estensioni non devono essere sincronizzate (migrazione di n+1 in n e una successiva migrazione inversa in n+1)
Lo sviluppatore del plug-in deve scegliere la strategia di implementazione più opportuna. La piattaforma non prevede nessuna API per la gestione automatica della migrazione dei dati di plug-in.
