Document Actions
Deploy library jar on extension instead of the library itself
| Autor: | Jorge Sanz |
|---|---|
| Fecha: | 06.02.2012 |
| Estado: | Aprobada |
| Prioridad: | Normal |
Note
la fecha seria la de presentación de la propuesta.
Miembros del CDT que deben votar la propuesta y su voto.
| Miembro | Voto |
|---|---|
| Álvaro Anguix | Blanco |
| César Ordiñana | Sí |
| Joaquín del Cerro | Blanco |
| Jorge Sanz | Sí |
| José Vicente Higón | |
| Manuel Madrid | |
| Nacho Brodin | Sí |
| Nacho Varela | Sí |
| Pablo Sanxiao | Sí |
Voto podrá ser:
- Sí
- No
- Blanco
- Exento
Esta propuesta debería estar resuelta antes de 13/02/12
Motivación y objetivo
El objetivo de esta propuesta es modificar la forma en que se gestionan los jars de las librerías de gvSIG Desktop 1.x respecto a su ubicación y la relación que tienen con los plugins que las usan
Equipo de trabajo
Enumeración del equipo de trabajo que ha de intervenir en la realización de la propuesta.
- Pablo Sanxiao
- Fran Puga
Propuestas a las que modifica
Esta propuesta no modifica a ninguna otra anterior.
Modificaciones a esta propuesta
No hay modificaciones a esta propuesta.
Descripción de la propuesta
Note
Esta propuesta parte de este ticket https://devel.gvsig.org/redmine/issues/219
Problema
El problema surge porque es muy habitual que un desarrollador toque el código de una librería y suba el jar al repositorio de la librería pero no al de la extensión que la emplea. La teoría dice que el responsable de subir el jar a la extensión sería el mantenedor de la extensión, pero esto en la práctica no está funcionando puesto que es complicado saber cuando se ha producido realmente un cambio.
Solución propuesta
Basándose en que en la situación actual, en que el número de desarolladores es bajo y todos tienden a tocar todo, se propone que la persona que toque el código de la librería sea la responsable de subir el jar actualizado a la extensión que corresponda. Para simplificar este paso, y que haya menos probabilidades de despiste a efectos prácticos se propone que el target de Ant por defecto para las librerías sea hacer deploy sobre la extensión que corresponda.
Nótese que cuando se hace appgvSIG.buildAll las extensiones tratan de traerse los jar de las librerías a su extensión, no es necesario tocar esto puesto que este copiado se hace con un failOnError = false, por lo que lo más operativo es dejarlo estar así.
Nótese que si un desarrollador independiente quiere emplear la librería y usa el target por defecto dará un error puesto que buscará una ruta que no existe. Además de que es improbable que esto suceda en la rama 1.x es facilmente, llegaría con dejar un comentario en build.xml indicándole cual es el target que debería emplear.
Nótese que esto no significa que la librería dependa de la extensión a nivel de código, el acoplamiento se produce solamente a nivel deploy.
Nótese que en este momento si bien no hay librerías dependiendo de extensiones, si que hay librerías dependiendo de librerías (por ejemplo libJCRS se despliega directamente sobre libFMAP) así que la solución propuesta ya se está en parte aplicando.
Otras posibles soluciones
Hacer que las extensiones dependan de las librerías y no de los jar. Es la solución que asegura el mantenerse siempre actualizado y evita subir binarios al repositorio, pero tiene como contra que obliga al desarrollador a descargar un montón de proyectos adicionales.
Justificación de votos negativos
No ha sido necesaria la justificación de los votos en contra de la propuesta.
Resolución
Se aprueba la propuesta el 20/02/2012 con cinco votos a favor, dos en blanco, dos abstenciones y ningún voto en contra.
