Control de política de actualización 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 las empresas con muchos usuarios del mismo producto basado en Eclipse (que suele ser uno comercial), pueden surgir diversos problemas en esta modelo:

  1. Las actualizaciones para los productos de gran tamaño (por ejemplo, conectores de más 500) también son grandes. Es posible que a los equipos de soporte de TI no les guste la idea de tener a cientos de desarrolladores bajando actualizaciones de 500MEG a sus máquinas individuales. 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 claramente no desean que los desarrolladores bajen actualizaciones directamente 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 (proxy) locales

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 conectores 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 conectores.

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.

Es posible que existan varios elementos url-map en el archivo. 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