Reglas para usar sitios de actualización en Eclipse?

Question

¿Conoces alguna documentación sobre las reglas de uso de sitios de actualización? He conseguido los últimos 2 años y medio, el sitio de actualización de nuestra empresa, y estos son los problemas que tengo para hacer frente a:

• No todos los proyectos utilizan la misma versión eclipse. Tuvimos proyectos que usaron eclipse 2.1 (WSAD), eclipse 3.0 (RAD 6), eclipse 3.2 (RAD 7), eclipse 3.3 y eclipse 3.4.
• El sitio de actualización de nuestra empresa empaqueta principalmente cosas juntas. Así que he escrito pequeños plugins (a veces fragements) para empacar, p. la configuración de Checkstyle para nuestra empresa junto con la versión actual de Checkstyle.
• Lanzamos dos veces al año nuevas versiones de lo que ha cambiado. Entonces, si tengo 1 sitio de actualización o 4, esto cambiará drásticamente la carga que tengo que tomar.

Así que la pregunta es: ¿Cuántos sitios de actualización deberíamos usar, y si el número es más de 1, cómo puedo minimizar el trabajo para mantener los sitios de actualización?

Answer 1

Sugiero poner todo en un servidor web y desplegar los paquetes para cada versión de Eclipse a una URL diferente:

http://your.server/eclipse-3.3/site.xml
http://your.server/eclipse-3.4/site.xml
etc.

Esto hará que sea fácil de implementar , para mantener las cosas separadas y hará que sea sencillo para los usuarios ver "ah, este es el indicado para mí".

Answer 2

Probablemente deberías estar utilizando características y categorías, segmentadas por la versión de eclipse.

| 
+-WSAD-2-1 Category 
| | 
| +- Checkstyle 3.1 Feature 
| | 
| `- Team Checkstyle configuration for Checkstyle 3.1 
| 
`-Eclipse-3-4 Category 
    | 
    +- Checkstyle 4.4 Feature 
    | 
    `- Tema Checkstyle configuration for Checkstyle 4.4 

Esto puede ser isomorfo con el mantenimiento de múltiples sitios de actualización, aunque se puede considerar:

• quedarse con el denominador común más bajo que funciona, y minimiza los errores
• que los plugins escritos para Eclipse 3.4 no puede se espera razonablemente que funcione para Eclipse 2.1.
• algunos baches de versión entre versiones de Eclipse causan una cierta cantidad de dolor de actualización para los escritores de plugin (por ejemplo, 3.0 a 3.1 fue un gran salto)
• La configuración entre diferentes versiones del mismo producto puede no ser compatible.
• versiones de la misma Plugin pueden tener un conjunto de características diferentes, pero no funciona en todas las versiones (por ejemplo Checkstyle 5 soporta Java 5, pero no puede funcionar con el plugin Checkstyle que trabaja con Eclipse 2,1)

Sin embargo Si no es posible o deseable tener múltiples niveles de categorías, promocionar las categorías sugeridas anteriormente para separar los sitios de actualización es el camino a seguir.

Esto tiene ventajas de implementación, ya que los usuarios pueden apuntar al sitio de actualización para la versión de IDE que están usando, pero es exactamente lo que intenta evitar.