Controlar la política de actualizaciones de Eclipse

Actualizaciones de Eclipse permite a los usuarios buscar actualizaciones para las características instaladas actualmente. Para cada característica instalada, Actualizaciones utiliza el URL incorporado para conectarse al servidor remoto y buscar nuevas versiones. Si hay actualizaciones, Eclipse permite a los usuarios iniciar el procedimiento de instalación. Tras bajar, instalar y reiniciar la plataforma, la nueva versión de la característica está lista para su uso.

En empresas que cuentan con muchos usuarios del mismo producto basado en Eclipse (generalmente un de tipo comercial), este modelo puede causar varios problemas:

  1. Las actualizaciones de productos muy grandes (por ejemplo, plug-ins de 500+) también son grandes. La idea de que cientos de desarrolladores bajen individualmente actualizaciones de 500MEG en su máquinas individuales puede no ser del agrado de los equipos de soporte de I/T. Aparte del ancho de banda, una petición de bajada tan grande puede fallar, lo que llevaría a varios intentos y a un aumento del tiempo de inactividad de los desarrolladores.
  2. Algunas empresas expresan explícitamente su deseo de que los desarrolladores no bajen directamente actualizaciones de Internet. Por ejemplo, podrían establecer un equipo de soporte local que no esté preparado para manejar las peticiones relacionadas con la versión del producto ya disponible en el sitio de actualizaciones del proveedor. Podría interesarles restringir las actualizaciones y los arreglos a los de la lista aprobada internamente. En teoría, podrían hacerlo estableciendo sitios de actualizaciones 'proxy' en la LAN (tras el cortafuegos).
  3. Una vez preparadas las actualizaciones en los sitios proxy, los administradores necesitan un método para permitir a los usuarios saber que hay actualizaciones disponibles.

2. La política de actualización acude al rescate

2.1 Soporte para crear sitios de actualizaciones locales (proxy)

El primer paso para un administrador de productos sería establecer un sitio de actualizaciones de Eclipse local en un servidor conectado a la LAN de la empresa (tras el cortafuegos). El sitio de actualizaciones sería un subconjunto del sitio de actualizaciones del producto en Internet, ya que contendría solamente características y plug-ins relacionados con las actualizaciones que la empresa desea que se apliquen en ese momento. Técnicamente, este sitio sería un sitio de actualizaciones de Eclipse regular con archivadores de site.xml, características y plug-ins.

Los administradores construirían este sitio de dos maneras:

  1. Los equipos de soporte del producto crearían un archivo zip del sitio de actualizaciones, disponible de inmediato para este fin concreto. Los administradores solamente deberán bajar el archivo zip desde la página Web de soporte del producto utilizando la herramienta que prefieran y desempaquetarlo en el servidor local. Este método es útil para archivos zip de gran tamaño que requieren gestores de descarga reiniciables modernos (los que pueden volver a empezar donde se quedaron en caso de problemas de conexión).
  2. Actualizaciones de Eclipse proporciona una herramienta para duplicar sitios de actualizaciones remotos por completo o permitir a los administradores seleccionar las actualizaciones y arreglos a descargar. Esta posibilidad de duplicación estaría totalmente automatizada y simplificaría mucho la tarea del administrador, pero depende del soporte de conexión de red de Actualizaciones.

2.2 Control de política de actualización común

Dado que las características tienen el URL del sitio de actualizaciones incorporado en el manifiesto, no tienen conocimiento de los sitios de actualizaciones locales establecidos por los administradores. Por consiguiente, es importante proporcionar la posibilidad de redirección. Este y otros valores de política de actualización pueden establecerse para un producto Eclipse creando un archivo de política de actualización y configurando Actualizaciones para utilizar ese archivo al buscar.

El archivo en cuestión utiliza el formato XML y puede tener cualquier nombre. El archivo puede establecerse en Preferencias > Instalar/Actualizar en el campo Política de actualización. El campo de texto está vacío por omisión: los usuarios pueden definir el URL del archivo de política de actualización. El administrador local gestiona el archivo y se comparte entre todas las instalaciones del producto. El compartimiento puede lograrse de dos maneras:

El archivo de política debe ajustarse a la siguiente DTD:

<?xml encoding="ISO-8859-1"?>

<!ELEMENT update-policy (url-map)*>
<!ATTLIST update-policy
>

<!ELEMENT url-map EMPTY>
<!ATTLIST url-map
    pattern    CDATA #REQUIRED
    url        CDATA #REQUIRED
>

url-map

Este elemento se utiliza para alterar temporalmente los URL de Actualizaciones incorporados en manifiestos de características. Al buscar nuevas actualizaciones, la búsqueda de Eclipse comprobará la política de actualización (si la hay) y comprobará si se ha especificado url-map para el prefijo de característica coincidente. Si se encuentra una coincidencia, se utilizará el URL correlacionado en lugar del incorporado. De esta manera, los administradores pueden configurar productos Eclipse para buscar actualizaciones en el servidor local tras el cortafuegos. Mientras tanto, las características de terceros instaladas por Actualizaciones de Eclipse continuarán actualizándose utilizando el mecanismo por omisión, ya que no encontrarán coincidencias en la política.

En el archivo pueden existir varios elementos url-map. Puede elegirse que los prefijos de características sean más o menos específicos. Por ejemplo, para redireccionar todas las actualizaciones de Eclipse, el atributo de patrón sería "org.eclipse". De forma similar, es posible utilizar un ID de característica completo como patrón si es necesaria la redirección según cada característica.

Pueden elegirse los patrones del archivo para reducir progresivamente las coincidencias potenciales. Esto puede dar como resultado múltiples coincidencias para una característica dada. En este caso, se utilizará la coincidencia con el patrón más largo. Por ejemplo:

<?xml version="1.0" encoding="UTF-8" ?>
<update-policy>
	<url-map pattern="org.eclipse" url="URL1"/>
	<url-map pattern="org.eclipse.jdt" url="URL2"/>
</update-policy>

En el caso anterior, se actualizarán todas las características de Eclipse a partir de URL1, excepto org.eclipse.jdt que utilizará URL2.

Los archivos de política de actualización no contienen series convertibles y, por lo tanto, no requieren un manejo de NL especial. En general, los archivos deberán utilizar la codificación UTF-8.

2.3 Descubrimiento automático de actualizaciones

La tercera parte de la solución global se trata en otro tema, pero se menciona aquí ya que forma parte integral de la solución. Las actualizaciones automáticas permitirán a Eclipse ejecutar búsquedas de actualizaciones con una planificación especificada (en cada inicio (el valor por omisión), una vez al día, una vez a la semana, etc.).

3. Resumen

Esta es la secuencia de pasos completa que compone la solución:

  1. El administrador asigna un servidor en la LAN de la empresa para alojar actualizaciones de productos localmente. Inicialmente no contiene sitios de actualizaciones. La máquina debe tener un servidor HTTP en ejecución.
  2. El administrador prepara un archivo de política de actualización en ese servidor e indica a todos los usuarios que establezcan la preferencia de política de actualización en el URL proporcionado.
  3. A medida que el proveedor del producto envía actualizaciones y arreglos a los sitios de actualizaciones, el administrador baja las actualizaciones soportadas al servidor local.
  4. La actualización automática ejecutada con la frecuencia planificada cuando el producto del cliente está activo recoge las actualizaciones locales y notifica al usuario
  5. El usuario decide instalar las actualizaciones descubiertas

Tareas relacionadas
Planificador de actualizaciones automáticas