Plataforma Eclipse
Instalación y actualización
Fecha de revisión: 06/14/01 10:45 AM - Versión: 0.12
Nota: El gestor de actualización se halla todavía en fase de desarrollo y es previsible que se efectúen cambios hasta que se consiga la plena estabilidad. Se ha puesto a disposición esta etapa para solicitar la opinión de los primeros en adoptarlo, bien entendido de que los detalles de los mecanismos de contribución podrían cambiar de forma sustancial.
|
Introducción
Escenarios
Convenciones de empaquetado
Conceptos
Archivo de componentes
Archivo de configuración
Información para la traducción del paquete
Consideraciones de Seguridad
Empaquetado del NL
Empaquetado del soporte específico para un objetivo
Empaquetado de las entregas de apoyo
Estructura de la instalación
Instalación completa o instalación de consulta
Distribución del sistema de archivos: Instalación completa
Archivos del entorno de trabajo
Distribución del sistema de archivos: Instalación de consulta
Lanzar Eclipse
Consideraciones de actualización
Actualización de componentes externos a la plataforma
Actualización de la plataforma
Actualización del JRE
Actualización de los archivos del producto
Actualización del soporte de lanzamiento
Recuperación de anomalías de actualización
Recuperación tras actualizaciones fallidas
Limpieza de la instalación
Funciones de Eclipse sin gestión
Consideraciones de instalación
Nueva
instalación
Instalación fusionada
Registro específico de la plataforma
Consideraciones de desarrollo
Independencia de la localidad de la instalación
Ejecutables nativos
Soporte para versiones de plug-in concurrentes
Migración de versión
Introducción
Este documento resume el soporte para la gestión de la entrega de funciones dentro de la plataforma Eclipse.
Escenarios
La plataforma Eclipse contiene de serie un gestor de actualización que se utiliza como parte de la instalación de funciones basadas en Eclipse, así como para la entrega de actualizaciones de servicios y la ampliación de funciones. Los escenarios siguientes son soportados en la versión inicial de Eclipse:
-
instalación tradicional del nuevo producto
En este escenario se empaqueta un producto construido utilizando Eclipse, utilizando tecnología de instalación específica para la plataforma, tal como el instalador MSI de Windows, RPM, InstallShield,
o cualquier mecanismo de archivo simple (p.ej. un archivo .zip). El empaquetador del producto sigue la convención de diseño de archivos de Eclipse descrita más adelante (consulte "Distribución del sistema de archivos: instalación completa"). Durante la instalación, se crea un árbol de instalación del nuevo producto en el sistema local de archivos, y el instalador copia los archivos empaquetados. Ello incluye una copia de la plataforma Eclipse, opcionalmente el entorno jre de Java y los plug-ins de cualquier producto que se ejecute en la plataforma Eclipse.
-
instalación fusionada tradicional
En este escenario se empaqueta un producto construido utilizando Eclipse, utilizando tecnología de instalación específica para la plataforma, tal como el instalador MSI de Windows, RPM, InstallShield,
o cualquier mecanismo de archivo simple (p.ej. un archivo .zip). El empaquetador del producto sigue la convención de diseño de archivos de Eclipse descrita más adelante (consulte "Distribución del sistema de archivos: instalación completa"). Durante la instalación, el instalador detecta que el usuario ya posee en su sistema una instalación basada en Eclipse (consulte la sección "Registro específico de la plataforma"). El instalador ofrece al usuario la opción de fusionar la nueva función con la instalación existente (la otra opción consiste en instalar la nueva función como una instalación nueva (escenario previo).
En caso de un archivo simple, el usuario que realice la instalación selecciona manualmente el directorio de instalación actual (sin ayuda proporcionada por la utilidad de compresión de archivos, como zip).
-
actualización de componentes
El entorno de trabajo estándar de Eclipse contiene un diálogo que permite actualizar en la red los componentes previamente instalados. Los metadatos empaquetados con cada componente permiten que el asistente determine la ubicación del servidor a actualizar.
Para que la actualización se active, deberá reiniciar la plataforma Eclipse.
-
añadir nuevos componentes
El entorno de trabajo estándar de Eclipse contiene un diálogo que permite "descubrir" nuevos componentes y añadirlos a la red. Para que los componentes recién añadidos se activen, deberá reiniciar la plataforma Eclipse.
Convenciones de empaquetado
Conceptos
Plug-in
Los desarrolladores de Eclipse construyen plug-ins. Los Plug-ins son las unidades básicas de ejecución reconocidas por el entorno de tiempo de ejecución de Eclipse. Por regla general, los plug-ins no se exponen a los usuarios que seleccionan funciones durante la instalación o actualización.
La razón es que los desarrolladores establecen los límites de los plug-in por razones de desarrollo (como la reutilización de funciones) y presentan un nivel erróneo de granularidad, en términos de lo que el usuario ve como la unidad de función.
Mientras se desarrollan los plug-in (que son modificados con frecuencia), su estructura interna de archivos reflejará lo que le convenga al desarrollador.
Esto dependerá generalmente de la herramienta de desarrollo que se utilice en particular.
La mayoría de veces, no obstante, el desarrollador preferirá configurar el plug-in para que se ejecute desde un árbol de directorios que contenga archivos .class expuestos, antes que ejecutarlos desde un .jar (ello requiere un paso extra para crear el .jar y todos sabemos que los desarrolladores odian los pasos extras). Además, en esta fase el desarrollador no presta atención especial a la información de versión del plug-in, ya que éste cambia continuamente.
Sin embargo, cuando el plug-in está listo para empaquetar, requiere su conversión a un formulario apto para su empaquetado e instalación. Ello suele significar la creación del .jar del tiempo de ejecución y la eliminación de los archivos de tiempo de desarrollo (fuente, archivos .class expuestos, etc.). También significa actualizar el manifiesto plugin.xml con la versión del plug-in oficial y reflejar la versión en el nombre de directorio del plug-in (para obtener más detalles, consulte "Soporte para la versión del plug-in concurrente").
Fragmento de Plug-in
Los fragmentos de Plug-in (o simplemente Fragmentos) permiten el empaquetado independiente de ciertos aspectos del plug-in de base. Ello incluye (aunque puede no limitarse a) los recursos traducidos para el plug-in, código específico de OS o del sistema de ventanas, o el contenido del plug-in destinado a usuarios alternos (p.ej. la información del desarrollador SDK suministrada con un plug-in). En tiempo de ejecución, los fragmentos se fusionan lógicamente con el plug-in de base. Desde el punto de vista del empaquetamiento, se pueden empaquetar físicamente con el plug-in de base, o empaquetar y servir por separado. Esto, por ejemplo, permite crear un "paquete de idioma", o un
"paquete de sistema operativo" concreto, independiente de la distribución de la función de base.
Componente
Un componente es típicamente un grupo de plug-ins y/o fragmentos de plug-in que entregan alguna función de usuario. Los componentes pueden exponerse al usuario como parte del proceso de empaquetado e instalación, porque representan una unidad de selección de función. Los componentes también representan una unidad de instalación (todos los archivos contenidos se instalan juntos en un mismo árbol de instalación). Los componentes llevan un identificador de versión.
Los componentes se empaquetan como un .jar de Java, contienen los plug-ins y fragmentos de plug-in necesarios, y un manifiesto de instalación de componentes (un archivo xml).
El gestor de actualización de Eclipse puede situar al/los componente/s .jar en un servidor de actualización para su descarga e instalación, o bien pueden utilizarse como la entrada en un proceso formal de empaquetado usando una de las tecnologías "tradicionales" de instalación. El formato y el manifiesto de instalación del componente jar se describen más adelante.
Configuración
Configuración es un mecanismo de agrupamiento versionado para un conjunto de componentes versionados. Puede, por ejemplo, utilizarse para especificar qué configuración de componentes fue construida y probada en conjunto como una versión concreta de un producto.
Las configuraciones se empaquetan como un .jar de Java, conteniendo el manifiesto de instalación de configuración (un archivo xml). El manifiesto contiene referencias a componentes que constituyen la configuración, junto con las restricciones de instalación y de actualización de versión. Adviértase que la configuración .jar no contiene los archivos de los componentes (únicamente referencias).
El/los .jar de configuración pueden situarse en un servidor de actualización para su descarga e instalación por el gestor de actualización de Eclipse, o pueden usarse como la entrada en un proceso formal de empaquetado, utilizando una de las tecnologías "tradicionales" de instalación. El formato y el manifiesto de instalación del jar de configuración se describen más adelante.
La implementación actual de Eclipse no permite la anidación de configuraciones.
Archivo de componentes (.jar)
Por costumbre, los componentes se identifican utilizando un identificador estructurado en base al nombre de dominio de internet del proveedor. Por ejemplo, la organización eclipse.org puede producir los componentes org.eclipse.platform. El identificador de componente se utiliza como parte del nombre del componente .jar, así como el nombre del directorio de componentes dentro de la estructura .jar (y por consiguiente del árbol de instalación). Como puede haberse instalado simultáneamente más de una versión de un componente dado, el nombre del componente .jar, así como su nombre de directorio,también codifican el identificador de versión. El identificador de versión sigue el formato definido por Eclipse para los identificadores de versión de plug-in (consulte el javadoc de la clase PluginVersionIdentifier). Se trata de un identificador numérico en tres partes que consta de componentes mayores, menores y de servicio (p.ej. 2.4.11)
El nombre presenta la forma
<componentId>_<version>
Por ejemplo,
org.eclipse.platform_1.0.3.jar
com.ibm.tools.jspeditor_3.1.0\install.xml
El componente jar posee la siguiente estructura de vía de acceso interna:
install/
components/
<componentId>_<version>/
install.xml
(otros archivos opcionales)consulte "Información para la traducción del paquete"
plugins/
<pluginId>_<pluginVersion>/
plugin.xml
(otros archivos de plug-in)
fragments/
<fragmentId>_<fragmentVersion>/
fragment.xml
(otros archivos de fragmentos, también pueden incluir plugin.xml)
El .jar contiene exactamente una vía de acceso install/components/ con exactamente un archivo install.xml. Contiene cero-o más plug-ins en sus directorios relativos (con calificador de versión). Contiene cero o más fragmentos de plug-in en sus directorios relativos (con calificador de versión). También contiene el directorio meta-inf/ producido por las utilidades jar de Java.
El dtd siguiente determina el formato del componente install.xml:
<?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
>
Las definiciones del elemento y de los atributos son las siguientes:
-
<component> - define el componente
-
label - etiqueta de visualización opcional (nombre)
-
id - identificador del componente necesario (ej. org.eclipse.platform)
-
version - versión del componente necesario (ej. 1.0.3)
-
provider-name - etiqueta de visualización opcional que identifica la organización que provee este componente
-
<description> - breve descripción del componente
-
<url> - especificación del/los URL de sitios que contienen actualizaciones de componentes, o componentes nuevos.
-
<update> - URL adonde conseguir actualizaciones para este componente
-
url - el URL en activo
-
label - etiqueta visualizable (nombre) para el sitio de referencia
-
<discovery> - URL donde conseguir nuevos componentes o configuraciones. En
general, un proveedor utiliza este elemento para aludir a su(s) propio(s) sitio(s), o al sitio asociado que ofrece componentes o configuraciones complementarios.
Eclipse utiliza este elemento simplemente como forma de distribuir el URL de sitios nuevos a sus clientes.
-
url - el URL en cuestión
-
label - etiqueta visualizable (nombre) para el sitio de referencia
-
<plugin> - identifica los plug-in que contiene
-
label - etiqueta de visualización opcional (nombre) del plug-in incluido
-
id - identificador del plug-in necesario
-
version - versión del plug-in necesario. El identificador de versión sigue el formato definido por Eclipse para los identificadores de versión de plug-in (consulte el documento java para la clase PluginVersionIdentifier).
-
<fragment> - identifica los fragmentos de plug-in contenidos
-
label - etiqueta de visualización opcional (nombre) del fragmento de plug-in incluido
-
id - identificador del fragmento de plug-in necesario. Adviértase que el identificador del plug-in de base forma parte del identificador del fragmento (ej. org.eclipse.platform_de_DE
como identificador para la traducción para la plataforma alemana, empaquetado como fragmento)
-
version - versión del fragmento del plug-in necesario. El identificador de versión sigue el formato definido por Eclipse para los identificadores de versión de plug-in (consulte el documento java para la clase PluginVersionIdentifier).
Archivo de configuración (.jar)
Por costumbre, las configuraciones se identifican utilizando un identificador estructurado en base al nombre de dominio de internet del proveedor. Por ejemplo, la organización eclipse.org puede producir la configuración org.eclipse.sdk. El identificador de configuración se utiliza como parte del nombre de la configuración .jar, así como el nombre del directorio de configuración dentro de la estructura .jar (y por consiguiente del árbol de instalación). Como puede haberse instalado simultáneamente más de una versión de una configuración dada, el nombre de la configuración .jar, así como su nombre de directorio,también codifican el identificador de versión. El identificador de versión sigue el formato definido por Eclipse para los identificadores de versión de plug-in (consulte el documento java para la clase PluginVersionIdentifier). Se trata de un identificador numérico en tres partes que consta de componentes mayores, menores y de servicio (p.ej. 2.4.11)
El nombre presenta la forma
<configurationId>_<version>
Por ejemplo,
org.eclipse.sdk_1.1.5.jar
com.ibm.wsa_1.0.1\install.xml
La configuración jar posee la siguiente estructura de vía de acceso interna:
install/
configurations/
<configurationId>_<version>/
install.xml
(otros archivos opcionales)consulte "Información para la traducción del paquete"
(archivos "product" )consulte "Lanzar Eclipse"
El .jar contiene exactamente una vía de acceso install/configurations/ con exactamente un archivo install.xml. También contiene el directorio meta-inf/ producido por las utilidades jar de Java.
El dtd siguiente determina el formato del componente install.xml:
<?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"
>
Las definiciones del elemento y de los atributos son las siguientes:
-
<configuration> - define la configuración
-
label - etiqueta de visualización opcional (nombre)
-
id - identificador de la configuración necesaria (ej. org.eclipse.sdk)
-
version - versión de la configuración necesaria (ej. 1.0.3)
-
provider-name - etiqueta de visualización opcional que identifica la organización que provee esta configuración
-
application - opcional, identificador de una extensión registrada en el punto de extensión de aplicación de eclipse. Si no se especifica, el identificador toma por omisión el de la aplicación del entorno de trabajo estándar de Eclipse. Ésta será la aplicación que se lanzará si la configuración contenida representa la aplicación "principal" que estaba instalada.
-
<description> - breve descripción de la configuración
-
<url> - URL opcional que especifica el/los sitio(s) que contienen actualizaciones de configuración
-
<update> - URL donde conseguir actualizaciones para esta configuración
-
url - URL actual
-
label - etiqueta visualizable (nombre) para el sitio de referencia
-
<discovery> - URL donde conseguir nuevos componentes o configuraciones. En
general, un proveedor utiliza este elemento para aludir a su(s) propio(s) sitio(s), o al sitio asociado que ofrece componentes o configuraciones complementarios.
Eclipse utiliza este elemento simplemente como forma de distribuir URL de sitios nuevos a sus clientes.
-
url - URL actual
-
label - etiqueta visualizable (nombre) para el sitio de referencia
-
<component> - identifica el componente configurado
-
label - etiqueta de visualización opcional (nombre) del componente configurado
-
id - identificador del componente necesario
-
version - versión del componente necesario
-
allowUpgrade - opcional, por omisión es "false". Indica al gestor de actualización si la configuración permite la actualización del componente a una nueva versión reducida del mismo componente (true) o si únicamente permite actualizaciones de servicio (false).
Una configuración nunca permite la actualización de un componente a una nueva versión principal. Tal cambio requeriría la previa actualización de la configuración.
-
optional - opcional, por omisión es "false". Indica al gestor de actualización si éste componente debe instalarse siempre como parte de esta configuración (false) o puede ser excluido (deseleccionado) de la instalación (true)
La implementación actual de Eclipse no permite la anidación de configuraciones, ni que se especifiquen reglas de
componente más complejas.
Información para la traducción del paquete
Varios de los atributos incluidos en los manifiestos de instalación son cadenas de caracteres dispuestas para su visualización mediante interfaces de usuario. Para facilitar su traducción, los valores de estos atributos utilizan la convención definida para los atributos traducibles de plugin.xml. Las series que comienzan por % hasta el primer espacio, son tratadas como claves de identificación de recursos (sin el %) y buscadas en un archivo de propiedades. Por ejemplo
label="%cfg Eclipse SDK for Linux"
da como resultado la búsqueda de un recurso en el archivo de propiedad correcto con la clave "cfg".
Si no se proporciona ningún archivo de propiedad, o no se halla la clave, se utilizará el valor de serie por omisión (a continuación de la clave %).
Los archivos de propiedad son nombrados como install_<locale>.properties utilizando el convenio de denominación del paquete compuesto de recursos de Java. Dentro del .jar de componente y de configuración, están situados en el mismo directorio que su archivo install.xml correspondiente.
Al acceder a los paquetes compuestos de recursos, el código puede seleccionar tanto la variante NL apropiada del manifiesto (implementando un algoritmo de búsqueda) y después crear un paquete compuesto utilizando
ResourceBundle b;
b = new PropertyResourceBundle(properties.openStream());
O también, utilizar el soporte de base de Java para localizar la variante NL correcta del manifiesto como sigue:
ResourceBundle b;
ClassLoader l;
l = new URLClassLoader(new URL[] {<targetDirectoryURL>}, null);
b = ResourceBundle.getBundle("install",Locale.getDefault(),l);
El paquete compuesto de recursos resultante puede utilizarse en IPluginDescriptor.getResourceString(String,ResourceBundle)
para devolver la cadena de caracteres correcta ya traducida para el atributo del manifiesto.
Consideraciones de seguridad
Los .jar de componente y de configuración pueden confirmarse utilizando las utilidades de seguridad estándar de Java (ej. jarsigner). En tiempo de ejecución, el gestor de actualización comprobará si el jar solicitado es suministrado por un proveedor de confianza, y si el contenido del jar no ha sido modificado desde su confirmación. El usuario tiene la opción de aceptar jar cuya confianza no haya sido demostrada. Los jar que hayan sido modificados después de su confirmación son rechazados por el tiempo de ejecución de Eclipse.
Empaquetado de NL
Los archivos NL se empaquetan en subdirectorios separados para cada entorno nacional soportado.
Los subdirectorios pueden definirse dentro del directorio del mismo plug-in (ej. definido "inline" con el plug-in), o bien pueden empaquetarse en fragmentos de plug-in separados. En cualquier caso, el tiempo de ejecución de Eclipse proporciona servicios para "soldar" el directorio de plug-ins de base y los archivos del entorno nacional apropiados en una sola estructura de acceso lógico (aunque estén físicamente empaquetados).
El empaquetado de archivos NL como fragmentos de plug-in da como resultado una estructura de instalación un poco más compleja. La principal ventaja es el hecho de que el contenido de NL puede añadirse a la base a posteriori (esto es, no
ha de enviarse al mismo tiempo). También permite que los fragmentos se desarrollen independientemente a la base (en lo que concierne a las actualizaciones de servicio).
A continuación podemos observar las estructuras de instalación alternativas resultantes para el empaquetado de NL.
Empaquetado de NL "inline" con plug-in
install/
plugins/
<pluginId>_<version>/
(archivos "plug-in")
nl/
<locale>/
(archivos NL)
Por ejemplo:
install/
plugins/
my.funky.plugin_1.0.1/
plugin.xml
my.jar ... contiene clases y recursos por omisión
nl/
de_DE/
my.jar ... contiene el delta traducido
Empaquetado de NL como fragmento de plug-in
install/
fragments/
<fragmentId>_<version>/
fragment.xml
nl/
<locale>/
(archivos NL)
Por ejemplo:
install/
fragments/
my.funky.plugin_german_1.0.1/
fragment.xml
nl/
de_DE/
my.jar ... contiene el delta traducido
Los nombres de directorio de entorno nacional siguen los convenios de denominación del estándar de Java del entorno nacional.
Adviértase que, en general, el contenido del plug-in de base debe siempre incluir los recursos NL por omisión, de modo que la función se comporte de modo razonable en ausencia el árbol de entorno nacional correcto (esto es, mejor mostrar la serie por omisión que los identificadores de recursos en el UI).
Los mecanismos de tiempo de ejecución, de formato fragment.xml y los API para gestión de directorios de NL y de fragmentos están descritos en otra parte de la documentación de la plataforma Eclipse.
Empaquetado del soporte específico para un objetivo
Los archivos de OS y los específicos del sistema de visualización en ventanas se empaquetan en subdirectorios separados para cada objetivo soportado. Los subdirectorios pueden definirse dentro del directorio del mismo plug-in (ej. definido "inline" con el plug-in), o bien pueden empaquetarse en fragmentos de plug-in separados. En cualquier caso, el tiempo de ejecución de Eclipse proporciona servicios para "soldar" el directorio de plug-ins de base y los archivos específicos del objetivo apropiados en una sola estructura de acceso lógico (no obstante estén físicamente empaquetados).
El empaquetado de archivos específicos del objetivo como fragmentos de plug-in da como resultado una estructura de instalación un poco más compleja. La principal ventaja es el hecho de que el contenido específico del objetivo puede añadirse a la base a posteriori (esto es, no ha de enviarse al mismo tiempo). También permite que los fragmentos se desarrollen independientemente a la base (en lo que concierne a las actualizaciones de servicio).
A continuación podemos observar las estructuras de instalación alternativas resultantes para el empaquetado de archivos específicos del objetivo.
Empaquetado del soporte específico de objetivo "inline" con plug-in
install/
plugins/
<pluginId>_<version>/
(archivos "plug-in")
os/
<os-name>/
(archivos específicos del sistema operativo)
ws/
<nombre del sistema de ventanas>/
(archivos específicos de WS)
Por ejemplo:
install/
plugins/
my.funky.plugin_1.0.1/
plugin.xml
my.jar
os/
solaris/
libfoo.so
ws/
motif/
my.jar
Empaquetado del soporte específico para objetivos como fragmento de plug-in
install/
fragments/
<fragmentId>_<version>/
fragment.xml
os/
<os-name>/
(OS-specific files)
ws/
<nombre del sistema de ventanas>/
(archivos específicos del WS)
Por ejemplo:
install/
fragments/
my.funky.plugin_solaris_1.0.1/
fragment.xml
os/
solaris/
libfoo.so
ws/
motif/
my.jar
Los identificadores de objetivo utilizados en los nombres de directorio son definidos por Eclipse
(vea el Javadoc de org.eclipse.core.boot.BootLoader).
Los mecanismos de tiempo de ejecución, el formato fragment.xml y los API para gestión de directorios específicos de objetivo y de fragmentos están descritos en otra parte de la documentación de la plataforma Eclipse.
Empaquetado de las entregas de apoyo
Los archivos de apoyo adicionales pueden empaquetarse directamente en los directorios del plug-in, o bien como fragmentos. Éstos pueden incluir muestras, ejemplos, documentación de consulta del desarrollador, casos de prueba u otras informaciones que no proporcionan directamente la función de usuario de base. Por lo general, la plataforma no especifica el emplazamiento y la utilización de estos archivos. Sin embargo, al empaquetarlos como fragmentos, la plataforma proporciona soporte para el acceso al espacio combinado plug-in/fragmento como un solo árbol lógico. Esto permite que el plug-in de base contenga únicamente el soporte de usuario principal, y entrega la información adicional únicamente cuando los fragmentos necesarios están también presentes.
Estructura de la instalación
Instalación completa o instalación de consulta
Eclipse proporciona soporte para 2 tipos de instalación:
-
Instalación completa. Ésta es la estructura del sistema de archivos resultante tras la ejecución del proceso de instalación. Los archivos se localizan en el sistema de archivos del modo requerido por la plataforma Eclipse para su ejecución directa.
La función Eclipse únicamente puede ejecutarse directamente tras la instalación completa.
-
Instalación de consulta. Ésta es la estructura de archivos existente en una ubicación de actualización de Eclipse, utilizada para seleccionar componentes y configuraciones instalables.
Distribución del sistema de archivos: Instalación completa
La instalación completa se define como la salida del proceso de instalación, tanto si se trata del resultado de una instalación "tradicional", como si es el resultado de la actuación del gestor de actualización. La plataforma Eclipse puede ejecutarse directamente a partir de una instalación completa.
La instalación completa de Eclipse contiene la estructura de archivos siguiente:
<installation root>/
install/
install.properties
components/
<componentId>_<version>/
install.xml
install_<locale>.properties (opcional)
configurations/
<configurationId>_<version>/
install.xml
install_<locale>.properties (opcional)
(otros archivos de "producto") (opcional)
plugins/
<pluginId>_<version>/
plugin.xml
(otros archivos de plug-in)
fragments/
<fragmentId>_<fragmentVersion>/
fragment.xml
(otros archivos de fragmentos, también pueden incluir plugin.xml)
La definición de los directorios y archivos es como la especificada anteriormente para los jar de componente y configuración.
El archivo install.properties contiene propiedades de lanzamiento configurables. Refleja la configuración actual de lanzamiento para la plataforma y las aplicaciones instaladas.
Su uso exacto se describe en la sección "Lanzar Eclipse". Este archivo es instalado inicialmente como parte de una nueva instalación. Es posteriormente actualizado únicamente por el gestor de actualización cada vez que se actualiza la instalación de Eclipse.
En caso de actualización por otros medios, de modo incompatible con la instalación original, se restaurará el último estado válido.
El archivo, del tipo de un archivo de propiedades de Java, contiene lo siguiente:
application=<applicationId>
application.configuration=<configurationId>_<version>
runtime=<pluginId>_<version>
Por ejemplo
application=
application.configuration=com.ibm.wsa_1.0.3
runtime=org.eclipse.core.boot_1.1.4
Las definiciones de propiedades son las siguientes:
-
application - identificador de la aplicación a ejecutar. Es el identificador de una extensión registrada en el punto de extensión org.eclipse.core.runtime.applications. Este es el mismo código de aplicación que la plataforma lanzará. Si no se especifica, toma por omisión el entorno de trabajo suministrado con Eclipse
-
application.configuration - nombre del directorio (en el árbol install/configurations/) de la configuración correspondiente a esta aplicación. Puede contener cualquier archivo de lanzamiento específico de aplicación (p.ej. splash image). Ello permite que el lanzador seleccione la versión correcta de estos archivos para su utilización al inicio.
-
runtime - nombre del directorio (en el árbol de plugins/) de la ubicación del boot.jar de la plataforma Eclipse. Permite que el lanzador seleccione la versión correcta de la plataforma a ejecutar. El gestor de actualización establece este valor cada vez que la plataforma es actualizada. Si ésta se actualiza mediante instalación tradicional, esta propiedad deberá ser establecida correctamente.
Los archivos installation.properties son creados por el instalador inicial.
Una vez instaladas, las propiedades de aplicación y de tiempo de ejecución pueden actualizarse. Únicamente se permite actualizar el sufijo de versión de la application.configuration (pero no el identificador de configuración "dominante").
Nota: como se especifica en esta sección, la instalación inicial de un producto basado en Eclipse deberá asimismo instalar el archivo install.properties que refleja los parámetros correctos de puesta en marcha inicial. Un error en ello dará como resultado la incapacidad de lanzar el producto.
Archivos del entorno de trabajo
En una instalación típica para un solo usuario, la <raíz de instalación> contendrá también los archivos del espacio de trabajo del usuario. Éstos se crean una vez que la plataforma ha sido iniciada. En una configuración de múltiples espacios de trabajo, la plataforma se inicia con el directorio del espacio de trabajo explícitamente especificado. Todo archivo creado como parte de la ejecución de la plataforma se graba en los directorios del espacio de trabajo.
Adviértase que en el escenario de múltiples espacios de trabajo, el usuario debe asegurarse de que únicamente se ejecute una instancia del gestor de actualización en un momento dado. Si la configuración del espacio de trabajo múltiple representa de hecho una instalación compartida multiusuario, la instalación compartida "administrador" deberá asegurarse de que los usuarios individuales tengan acceso únicamente de lectura a la raíz de instalación.
Distribución del sistema de archivos: Instalación de consulta
La estructura del archivo de instalación de consulta es similar a la de la instalación completa. Contiene lo siguiente:
<installation root>/
install/
components/
install.index (opcional)
< componentId>_<version>/
install.xml
install_<locale>.properties (opcional)
<componentId>_<version>.jar
configurations/
install.index (opcional)
<configurationId>_<version>/
install.xml
install_<locale>.properties (opcional)
<configurationId>_<version>.jar
La instalación de consulta puede crearse simplemente desenzipando parcialmente el manifiesto de instalación (y todo paquete compuesto de recursos de instalación) desde el jar de componentes o de configuración, y a continuación copiando el jar en su totalidad en la estructura de directorios resultante (similar al install.xml). Exponer el install.xml permite al gestor de actualización determinar qué hay disponible en un sitio dado. Una vez seleccionado, el .jar correspondiente es trasvasado e instalado.
Cuando se accede al sitio de instalación de consulta mediante un protocolo distinto del de entrada/salida directa de archivos, el sitio debe también contener el install.index opcional (en los directorios components/ y configurations/). Este archivo es un simple directorio de "tabla de contenidos". Contiene los propios nombres de subdirectorio en líneas separadas.
Por ejemplo:
<installation root>/
install/
components/
install.index
org.eclipse.platform_1.0.1/
org.eclipse.jdt_2.9.5/
org.eclipse.pde_1.0.4/
El archivo install.index debería contener
org.eclipse.platform_1.0.1
org.eclipse.jdt_2.9.5
org.eclipse.pde_1.0.4
El archivo install.index no es necesario al aludir al "sitio" mediante entrada/salida de archivo directo (como URL del"archivo"). Adviértase, no obstante, que si el archivo está presente, es utilizado incluso en caso de acceso de entrada/salida de archivo directo. Así, el archivo puede ser utilizado por la administración del sitio para controlar qué configuraciones y componentes están expuestos. En general esto es útil cuando los componentes contenidos en las configuraciones no están dispuestos para ser trasvasados e instalados como elementos separados (esto es, gestionados únicamente mediante alguna configuración).
En tal caso las configuraciones se expondrían directamente, pero no así los componentes. Los componentes únicamente serían localizables mediante las configuraciones expuestas.
Lanzar Eclipse
Antes de tratar algunas de las consideraciones de actualización, es importante comprender cómo se inicia la plataforma Eclipse. Ello supone lo siguiente:
-
el directorio de la raíz de instalación contiene el mandato de lanzamiento del "producto".
Puede ser un sencillo mandato de "script" (ej.: .bat), o bien la función de este script puede ser realizada por un sencillo lanzador ejecutable (ej.: .exe).
En ambos casos, el mandato de lanzamiento efectúa 3 cosas
-
lee el archivo install.properties (vea la descripción previa de este contenido).
Localiza su splash image en el directorio de configuración de la aplicación (propiedad application.configuration), y lo visualiza.
-
selecciona la JVM a ejecutar y la lanza (mediante el mandato de java, o cargando directamente los ejecutables de JVM). El criterio de selección de jre incluye la ubicación de jre explícitamente aprobada, y la ubicación relativa al lanzador, o valor de la variable de entorno (compartiendo el jre común en el sistema)
-
causa la carga de la clase Main desde startup.jar, y la ejecución de su método principal(...)
-
La clase Main comprueba la ubicación de los ejecutables de la plataforma eclipse (propiedad del tiempo de ejecución) y el identificador de la aplicación que la plataforma va a ejecutar (propiedad de la aplicación, el entorno de trabajo es la aplicación por omisión que proporciona Eclipse). Main localiza el boot.jar de la plataforma y carga el BootLoader de la plataforma desde él. Da el control al BootLoader aprobando el identificador de la aplicación como argumento (más cualquier otro argumento de inicio)
-
El BootLoader provoca el inicio del tiempo de ejecución del núcleo de la plataforma. Ello hace que se cargue y resuelva (configurando los plug-in que reúnan los requisitos necesarios para su ejecución) el registro del plug-in.
-
El BootLoader busca el nombre de la aplicación (aprobado como argumento) en el registro del plug-in, y, si lo encuentra, activa el plug-in de la aplicación y le entrega el control.
-
La aplicación iniciada (ej. el entorno de trabajo), activa y llama a otros plugins en caso necesario
Nota: El lanzador por omisión proporcionado con la versión actual de la plataforma Eclipse de hecho no procesa el archivo install.properties (como se describe en los pasos 1 y 2 anteriores). Simplemente localiza la pantalla splash por omisión y el tiempo de ejecución de la plataforma relativo a sí mismo.
Consideraciones de actualización
Actualización de componentes ajenos a la plataforma
Los componentes ajenos a la plataforma entregan plug-ins que se ejecutan "al inicio" de la plataforma.
El gestor de actualización simplemente instala los directorios y archivos del plug-in necesario. Éstos serán detectados y procesados la siguiente vez que se inicie la plataforma.
El gestor de actualización nunca actualiza la estructura de directorios de un plug-in ya existente.
Únicamente instala la versión de un plug-in que no existiera previamente.
Si el directorio del plug-in ya existiera (ej. incluido en algún otro (versión de) componente), no se instala nuevamente. El gestor de actualización no verifica que el contenido del directorio existente coincida con el del jar del componente. En consecuencia, el identificador de versión del plug-in deberá estar reflejado correctamente en el nombre del directorio del plug-in.
Actualizar la plataforma
La versión actual de la plataforma Eclipse no permite a la propia plataforma su actualización utilizando el gestor de actualización. Las actualizaciones de la plataforma requieren su manejo mediante mecanismos de instalación tradicionales.
Actualización del JRE
La versión actual de la plataforma Eclipse no permite a la propia plataforma su actualización mediante el gestor de actualización. Las actualizaciones del JRE requieren su manejo mediante mecanismos de instalación tradicionales.
Actualizar archivos de producto
La instalación de un paquete incluye típicamente varios archivos de todo tipo que acaban siendo situados en el directorio de lanzamiento del producto. Esto incluye varios archivos léeme, splash image(s), copias de los acuerdos de licencia, notas del release, etc. Estos archivos deberán empaquetarse como parte de los jar de componentes y de configuración (como archivos adicionales arbitrarios dentro de la configuración o directorio de componentes específico (al igual que install.xml)). Son permitidos tanto los archivos individuales como los subdirectorios. De este modo, estos archivos son empaquetados, entregados e instalados como parte del jar versionado de componentes o de configuración.
Por ejemplo, el jar de componentes puede contener
install/
components/
com.xyx.etools_1.3.5/
install.xml
splash.bmp
readme.txt
license.txt
notes/
jspedit.txt
debug.txt
Actualización del soporte de lanzamiento
La versión actual de la plataforma Eclipse no permite la actualización del lanzador (.exe, startup.jar) mediante el gestor de actualización. Las actualizaciones del lanzador requieren su manejo mediante mecanismos de instalación tradicionales.
Recuperación de anomalías de actualización
Se han de tener en cuenta dos escenarios.
-
anomalías controladas - son varias anomalías de acceso, descarga, desenzipado, etc. detectadas por el gestor de actualización. El gestor de actualización contiene la lógica necesaria para recuperarse de estas anomalías.
-
anomalías "incontroladas" - son anomalías repentinas (ej: pérdida de alimentación)
en medio del proceso de actualización, antes de que el gestor de actualización tenga opción de completar la operación. Éstas se detectan al iniciar la plataforma. El árbol de instalación se comprueba respecto del último estado conocido y cualquier modificación parcial es eliminada del árbol de instalación.
Recuperación de actualizaciones fallidas
El gestor de actualización mantiene una descripción del estado de la configuración actual de la instalación. Ello incluye el listado de configuraciones y componentes "activos" (el árbol de la instalación actual puede contener configuraciones y versiones de componentes adicionales que se encuentran de hecho ocultas a resultas de actualizaciones ulteriores).
Cada vez que el gestor de actualización efectúa una actualización y guarda esta información (la acción de guardar se efectúa a la conclusión de la plataforma), se clona la información del estado, y el estado previo se mantiene como una secuencia cronológica de actualizaciones. El gestor de actualización mantiene varias generaciones de estado (el número de estados previos es una opción configurable). Las viejas versiones del estado y sus configuraciones y componentes correspondientes son recogidas con regularidad (borradas), como parte del proceso de limpieza del gestor de actualización.
Las copias de seguridad del estado proporcionan un mecanismo para su recuperación tras actualizaciones fallidas. En este escenario, "fallidas" significa que el gestor de actualización trasvasó y aplicó satisfactoriamente un cambio, pero este cambio está causando problemas.
Limpieza de la instalación
El gestor de actualización ajusta periódicamente el contenido del árbol de instalación.
Solamente retiene las referencias a componentes y configuraciones de las generaciones más recientes del estado de actualización (el número de estados retenido es una opción configurable). La limpieza se ejecuta como parte de la operación del gestor de actualización y no requiere ser desencadenada explícitamente.
Funciones de Eclipse sin gestión
Además de las configuraciones y componentes "formalmente" instaladas, la plataforma Eclipse también tolera plug-ins y fragmentos de plug-in que son situados directamente en el árbol de instalación sin ningún manifiesto de instalación correspondiente que los describa. Estos plug-in y fragmentos son reconocidos en el tiempo de ejecución, pero no pueden ser actualizados o eliminados utilizando las funciones del gestor de actualización (se encuentran "sin gestión"). Este respaldo está orientado específicamente a los escenarios de desarrollo de plug-in, en un intento de eliminar la estructura de desarrollo de instalación y empaquetado. El instalador tradicional no instalará plug-ins y fragmentos de ellos que estén sin gestión.
Consideraciones de instalación
Desde el punto de vista de la instalación, Eclipse hace distinción entre una instalación que establece una nueva plataforma base de Eclipse (jre, plataforma y aplicación "dominante"), y aquella que simplemente contribuye (fusiona) componentes nuevos en una base ya existente.
Nueva instalación
Actualmente, la instalación de una plataforma nueva debe efectuarse utilizando una tecnología de instalación tradicional, como el instalador MSI de Windows, RPM, InstallShield, o un mecanismo de archivo simple (p.ej., un archivo .zip). El instalador es responsable de asegurarse de que la estructura de archivos resultante (tras la terminación de la instalación) sigue las especificaciones descritas en este documento.
El instalador necesita llevar a cabo lo siguiente:
-
establecer una raíz nueva de instalación de plataforma Eclipse
-
opcionalmente registrar la raíz de la nueva plataforma con el apropiado registro específico para el sistema operativo.
-
instalar una copia del Entorno de tiempo de ejecución de Java (JRE), o asegurarse de que un JRE ya existente esté correctamente configurado para su uso con Eclipse
-
instalar la plataforma Eclipse (al menos los componentes org.eclipse.core y org.eclipse.ui)
-
instalar la configuración de la aplicación "dominante". Típicamente, esto incluye la configuración de la aplicación completa más todos los componentes necesarios (y sus correspondientes plug-ins y fragmentos). Al menos, instalar una configuración "provisional" para la aplicación que especifique una ubicación de actualización que contenga la función de la aplicación misma (nótese que en la implementación actual el usuario debe desencadenar explícitamente ladescarga/actualización tras iniciar Eclipse).
-
instalar el archivo inicial install.properties como se ha descrito anteriormente (valores de configuración del inicio).
Debe proporcionarse el correspondiente desinstalador "tradicional" para eliminar la aplicación "dominante" y su árbol de plataforma Eclipse. Por lo general, el desinstalador es el encargado de revertir las acciones de su instalador. Adviértase, no obstante, que debido a que el contenido del árbol de instalación de Eclipse puede ser modificado como resultado normal de la utilización del gestor de actualización de Eclipse, el desinstalador "tradicional" puede en realidad no encontrar los archivos que se instalaron originalmente. Alguno de los archivos puede que ya no exista (fueron eliminados por el gestor de actualización), y puede que el árbol de instalación contenga ahora archivos adicionales que no fueron instalados originalmente (ej. actualizaciones aplicadas). Como resultado, por lo general un desinstalador "tradicional" no será capaz de eliminar completamente la instalación de la aplicación.
Para compensar las modificaciones efectuadas por el gestor de actualización, el desinstalador "tradicional" puede forzar la eliminación de todos los archivos incluidos en los directorios de instalación de Eclipse siguientes:
-
install/ - contiene información de la configuración de instalación (sin datos del usuario)
-
plugins/ - contiene ejecutables de los plug-in, etc. (sin datos del usuario)
-
fragments/ - contiene ejecutables de los fragmentos de plug-in, etc. (sin datos del usuario)
Otros directorios que se hallen en el árbol de instalación pueden contener datos del usuario y no deberían eliminarse.
Instalación fusionada
En cuanto se haya establecido la instalación de la plataforma Eclipse (ver la sección previa), podrán añadirse a la plataforma componentes y configuraciones adicionales, utilizando el gestor de actualización de Eclipse o un instalador "tradicional". En este último caso, el instalador es el responsable de asegurar que la estructura de archivos resultante (al término de la instalación) siga la especificación descrita en este documento.
El instalador necesita llevar a cabo lo siguiente:
-
detectar automáticamente la ubicación de una plataforma Eclipse ya instalada (en sistemas que den soporte a un mecanismo de registro (ver abajo)), o solicitar al usuario dicha ubicación
-
instalar los componentes y configuraciones apropiados (junto con los correspondientes plug-ins y fragmentos)
-
opcionalmente salvar un archivo de "raíz" de instalación fusionada, para su utilización durante la desinstalación "tradicional" (ver abajo)
La utilización de un desinstalador "tradicional" para una instalación fusionada requiere un cuidado adicional. Por lo general, los desinstaladores nunca deberían intentar eliminar los archivos de programas instalados realmente. La razón es que los archivos que se instalaron originalmente puede que ya no existan, o que alguno de los archivos que se instalaron haya sido actualizado como resultado normal de la operación de Eclipse. Como resultado, intentar eliminar directamente los archivos instalados originalmente puede, en el mejor de los casos, funcionar correctamente, o no causar ningún efecto en absoluto, y en el peor, puede dar como resultado la eliminación arbitraria de parte del soporte instalado (causando fallos imprevisibles tras el siguiente lanzamiento de la aplicación). Esto es aún más grave cuando los componentes o plug-ins son compartidos. Únicamente en caso de que se garantice que una configuración o un componente no hayan sido actualizados, y se garantice que no sean compartidos, podrán eliminarse directamente tales archivos.
Deberá tenerse cuidado al utilizar tecnologías de instalación que no permitan el control sobre el proceso de desinstalación (esto es, suprimir la eliminación de archivos instalados). RPM en Linux es un ejemplo de ello. En tales casos, la tecnología del instalador en particular debiera evitar las instalaciones fusionadas, o no debería ejecutarse nunca la desinstalación resultante.
Un desinstalador "tradicional" puede dar soporte a una eliminación sin peligro de las funciones instaladas al utilizar los archivos de "raíz" de instalación fusionada. Éstos se instalan opcionalmente como parte de la instalación fusionada y actúan como un ancla para las configuraciones y componentes correspondientes. La plataforma Eclipse detecta la eliminación de los archivos "raíz" durante el inicio, y elimina sin peligro las configuraciones y los componentes listados.
Nota: al contrario que los archivos de configuración y componentes mismos, los archivos "raíz" no están sujetos a modificaciones por el gestor de actualización. En consecuencia, un desinstalador "tradicional" puede contar con que sigan en su sitio una vez instalados.
Al instalarse, los archivos "raíz" se sitúan en el directorio install/info/ dentro del árbol de instalación de Eclipse (igual que los directorios install/configurations e install/components). Los archivos utilizan el convenio de denominación siguiente:
<merged-installation-identifier>.install
La plataforma Eclipse no especifica el formato del identificador (no lo interpreta de ningún modo). Para minimizar las posibilidades de crear conflictos de denominación, es altamente recomendable que el identificador utilice un convenio de denominación basado en el nombre de dominio de internet del proveedor (ej. com.xyz.toolpack.install).
El contenido del archivo "raíz" utiliza el formato de archivo propietario de Java, conteniendo lo siguiente:
configurations=[<configId>_<version> [, <configId>_<version>]*
]
components=[<compId>_<version> [,<compId>_<version>]*
]
donde
[]elemento opcional
* grupo de repetición
(en castellano llano, ambas propiedades son un listado separado por comas de los identificadores con sufijo de versión correspondientes)
Registro específico de la plataforma
Nota: esta sección describe una sugerencia de "buena costumbre". Sin embargo, no es necesaria para la correcta ejecución de la plataforma Eclipse.
Se sugiere que los productos basados en Eclipse utilicen un mecanismo de registro de OS, para hacer un seguimiento de todas las ubicaciones de plataformas Eclipse instaladas. Ello permite una búsqueda simple cuando haya que decidir entre crear una nueva instalación de plataforma, o fusionar componentes en una existente. En aquellas plataformas que no provean tales mecanismos de registro, el usuario será instado a identificar explícitamente los directorios de instalación de Eclipse.
El instalador típicamente ofrece crear una instalación nueva, o fusionar componentes en una instalación ya existente. La creación de instalación nueva deberá asimismo actualizar las estructuras de registro.
En Windows, el registro de Windows se utiliza para tal fin. A continuación podemos observar la estructura de claves de registro sugerida para identificar los directorios de instalación de la plataforma Eclipse:
eclipse.org/
platforms/
<product name>
La clave <product name> identifica al proveedor y/o la aplicación dominante que creó la nueva instalación de plataforma Eclipse.
La clave completa se correlaciona con los atributos siguientes
label = etiqueta visualizable para la clave <product name>. Localizada en el momento de la creación.
directory = <vía de acceso absoluta>
Consideraciones de desarrollo
Independencia de la localidad de la instalación
El interfaz API de Eclipse permite que un plug-in que se esté ejecutando obtenga una referencia a su directorio de instalación. Esto se cumple haciendo una llamada a IPluginDescriptor.getInstallURL(). La llamada obtiene como resultado el java.net.URL. Los plug-in en ejecución acceden a todos los recursos necesarios relativos a este URL. El protocolo URL da soporte a la redirección necesaria al directorio del plug-in local, la antememoria del plug-in, CD (instalación mínima) o servidor. La manera típica en que un plug-in accede a sus recursos es abriendo una corriente de entrada en el URL y leyendo el contenido del recurso. Como se toma por asumido que la ubicación de la instalación es de sólo lectura, el plug-in ejecutante no debería jamás intentar escribir utilizando el URL devuelto.
Ejecutables nativos
Las bibliotecas nativas de Java utilizadas por los plug-ins de Eclipse no requieren ningún manejo especial. Son instaladas como parte de la estructura de directorios del plug-in y cargadas por el cargador de la clase de plataforma (jdk 1.2+).
Los componentes nativos de un sistema operativo específico (como ActiveX) requieren una instalación personalizada, no manejada por el gestor de actualización de Eclipse. El instalador personalizado registra los componentes con los servicios apropiados al OS y actualiza las vías de acceso a búsquedas estándar. La plataforma Eclipse no proporciona ningún control automatizado de componentes nativos necesarios. El código del plug-in es necesario para implementar la lógica de comprobación/recuperación necesaria. Es posible crear un plug-in "marcador" como parte del instalador personalizado para que indique la presencia de componentes nativos y permitir que otros plug-ins especifiquen la dependencia. Sin embargo, este método no es infalible y no puede tomarse como una garantía absoluta de una dependencia nativa satisfactoria.
Soporte para versiones de plug-in concurrentes
La plataforma Eclipse permite la instalación concurrente de múltiples versiones de un plug-in. Esto cubre escenarios donde un usuario instala dos productos basados en Eclipse que contienen versiones diferentes del mismo plug-in. Ambas versiones pueden instalarse en la raíz de programas común. En función de las reglas de configuración (tratadas después), la plataforma generalmente utiliza durante la ejecución únicamente la versión más reciente del plug-in. No obstante, si el usuario posteriormente desinstala uno de los productos, la estructura de instalación del otro producto se mantiene sin cambios (esto es, contiene la versión correcta del plug-in que se instaló con el producto).
La plataforma Eclipse también permite que múltiples versiones del mismo plug-in estén simultáneamente configuradas y ejecutadas. Esto se orienta específicamente a los plug-in que contengan bibliotecas de tiempo de ejecución compartidas. Un usuario dado del tiempo de ejecución compartido puede querer especificar una dependencia en una versión específica del plug-in.
Este plug-in debe declarar únicamente sus bibliotecas de tiempo de ejecución(en la sección <runtime> de plugin.xml), y no debe declarar ninguna otra contribución a la plataforma (específicamente no debe declarar puntos de extensión ni extensiones de contribución).
Para soportar esto, la plataforma Eclipse define un plan para identificar a los plug-in, una convención para denominar a los directorios de plug-in en el sistema de archivos, y un conjunto de reglas para configurar y ejecutar plug-ins que se localicen durante el inicio de la plataforma.
Los plug-in se identifican mediante una combinación de cadena de caracteres estructurada de modo similar al nombre del paquete de Java y de identificador de versión multidecimal. El identificador de versión consiste en un componente mayor que indica una generación incompatible y un componente menor que indica una evolución compatible del plug-in.
-
id - identificador único del plug-in. Es una cadena de caracteres que asemeja el nombre del paquete de Java. El plan de identificación evita el choque de denominaciones mediante una simple convención de denominación jerárquica basada en los nombres de dominio de internet registrados de proveedores individuales que fabriquen plug-ins. Por ejemplo, org.eclipse.ui y edu.xyz.tools son ejemplos válidos de identificadores únicos de plug-in.
-
version - identificador multidecimal. Sigue la definición descrita para la clase PluginVersionIdentifier (major.minor.service)
Como pueden instalarse físicamente múltiples versiones del mismo plug-in en el mismo árbol de archivos, los directorios de cada plug-in deben ser identificados excepcionalmente para prevenir que múltiples versiones del mismo plug-in sean recubiertas accidentalmente. El nombre de directorio de plug-in recomendado es el formado por la combinación del identificador exclusivo del plug-in y del identificador de versión. El carácter subrayar "_" se utiliza para separar la cadena de caracteres de la versión de la cadena de caracteres del nombre.
A continuación tenemos ejemplos de nombres de directorio para los plug-in correspondientes.
Plug-in |
Versión |
Nombre de directorio recomendado |
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 plataforma proporciona un API para que se ocupe de los identificadores de versión
-
IPluginDescriptor.getVersionIdentifier() - devuelve el identificador de versión de un plug-in específico
-
implementación de clase de PluginVersionIdentifier. Los métodos de esta clase permiten el acceso a los componentes mayor y menor del identificador. También implementa la comparación de igualdad y compatibilidad de versiones
Hay una consideración adicional para los plug-ins que permiten una ejecución simultánea y además graban el estado o los datos de trabajo (ver Plugin.getPluginStateLocation()
y IProject.getPluginWorkingLocation(IPluginDescriptor)). Más allá del tema de la migración de versión (ver sección siguiente), los plug-ins son también responsables del manejo del acceso simultáneo desde múltiples versiones ejecutándose del mismo plug-in a los recursos de plug-in compartidos. Los plug-ins deben utilizar las prestaciones de los API de acceso a archivos seleccionados para coordinar el acceso simultáneo.
Migración de versión
Debido a la naturaleza dinámica de la configuración de la plataforma, las implementaciones de plug-in deben ser conscientes de las emisiones de migración que puedan surgir durante la ejecución. A diferencia de los productos tradicionales, las soluciones basadas en Eclipse realmente no "vienen juntas" hasta que el usuario inicia la plataforma.
La plataforma proporciona servicios básicos que pueden ser utilizadas por el plug-in para manejar cada una de las situaciones de migración, no obstante, en última instancia es responsabilidad del desarrollador del plug-in su uso correcto.
Cuando los plug-in se ejecutan, pueden grabar información específica del plug-in en varias ubicaciones de trabajo. Las referencias a las ubicaciones de trabajo se obtienen utilizando las siguientes llamadas a API
-
Plugin.getPluginStateLocation() - devuelve la ubicación del estado de trabajo de toda la plataforma al plug-in
-
IProject.getPluginWorkingLocation(IPluginDescriptor) - devuelve la ubicación de trabajo del plug-in dentro del proyecto de referencia.
Cada plug-in es responsable del manejo de la migración de sus datos de trabajo.
Los plug-ins deben tener en consideración dos escenarios básicos
-
migración hacia adelante - se configuró una nueva versión de un plug-in y necesita migrar los datos escritos por la versión previa. Esto se basa en la suposición de que la versión n+1 de un plug-in puede leer datos escritos por la versión n del mismo plug-in.
-
migración hacia atrás - una versión de un plug-in que se configuró en una invocación previa de la plataforma es eliminada, y una versión anterior del mismo plug-in deviene configurada (la versión más reciente escondía la antigua). Este es un escenario más problemático porque por regla general no se puede asumir que la versión n de un plug-in pueda leer datos escritos por la versión n+1 del mismo plug-in.
El escenario de migración hacia adelante necesita la nueva versión del plug-in para detectar los datos escritos por la versión anterior, y para leer, convertir y reescribir los datos. Esto puede realizarse la primera vez que se activa la nueva versión del plug-in (Plugin.startup()) o mientras se accede a las áreas de trabajo. Por lo general, el primer acceso es más apropiado para migrar los datos de "estado" del plug-in, y el segundo para migrar los datos del proyecto.
La migración hacia atrás necesita algo de trabajo extra por parte del desarrollador del plug-in. En esencia, la versión n+1 del plug-in necesita escribir datos de modo que la versión n pueda al menos detectar esta situación. Existen varias técnicas posibles que los plug-ins pueden utilizar para manejar este panorama.
-
detectar formatos de datos incompatibles y manejarlos "gentilmente" (esta detección puede efectuarse mediante los datos de versión o consiguiendo un error de datos mientras se lee).
Si los datos del plug-in son ilegibles, vuelva al funcionamiento inicial por omisión (como si no se hubiera encontrado ningún estado anterior). El inconveniente de este acceso es la pérdida de datos (ej. los valores del plug-in).
-
la versión n+1 escribe toda la información básica utilizando el formato de la versión n, y crea archivos separados (no reconocidos por n) para cualquier información ampliada. La versión n+1 debe tolerar que los archivos básicos y los archivos de extensión no sintonicen (n+1 migrado a n y posteriormente de vuelta a n+1)
-
utilizar un formato de serialización autodescriptor que identifique el contenido básico y las extensiones específicas para la versión. Las extensiones pueden conllevar calificadores adicionales
(ej. "ignorar si no se entiende", "debe entenderse", etc). La versión n de un plug-in puede leer datos escritos por la versión n+1 (valor absoluto que acata cualquier calificador).
Si la versión n actualiza cualquiera de los datos básicos, reescribe el archivo dejando intactas las extensiones de la versión n+1. Las extensiones calificadas con "debe entenderse" no son reescritas. La versión n+1 debe tolerar que el contenido básico y las extensiones no sintonicen (n+1 migrado a n y posteriormente de vuelta a n+1)
El desarrollador del plug-in es responsable de elegir la estrategia de implementación apropiada. La plataforma no proporciona ningún API específico para el manejo automático de la migración de datos del plug-in.
