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:

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:

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:

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:
  1. 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.
  2. 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:

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:
  1. 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
  2. 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.
  3. 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).
  4. 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.
  5. 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:
  1. Interruzioni controllate - si tratta di errori relativi ad accessi, download, decompressioni, rilevati dal gestore degli aggiornamenti, che è in grado di risolvere tali malfunzionamenti.
  2. 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:

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:

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:

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.

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

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

Ogni plug-in deve gestire la migrazione dei propri dati di lavoro. Vi sono due ipotesi da considerare:
  1. 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.
  2. 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.

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.