[Gvsig_desarrolladores] Buenas prácticas para la instalación de extensiones

Joaquin del Cerro jjdelcerro.gvsig en gmail.com
Mie Mayo 15 15:38:54 CEST 2013


El 14/05/13 10:52, David Deman escribió:
> Hola,
> realizando una extensión me preguntaba si es mejor que cree una librería
> nueva que utilice la extensión o ampliar la funcionalidad a una ya existente
> creando nuevas clases. Y otra pregunta es cuales son los pasos aconsejables
> para instalar una extensión propia. Yo lo que he hecho es copiar
> directamente la carpeta de la extensión compilada a la carpeta extensiones
> de gvSIG, pero igual hay algún método más intuitivo. Al igual que la
> librería que he modificado, he reemplazado el jar, es por ello que no se si
> es mejor crear una librería a parte para no machacar el gvSIG original.
> Un saludo,
> David
> 
> 


Hola David,
te cuento pensando en la 2, pero deberia ser aplicable todo a la 1.

Sobre lo de crear una libreria o ampliar la funcionalidad de una ya
existente; pues segun. Si lo que pretendes es añadir funcionalidad a una
libreria de otro plugin, entonces mejor que crees una libreria
especifica para el nuevo plugin. Te puede ocasionar problemas actualizar
librerias de otros plugins. Imagina que quisieses actualizar la libreria
"AAA.jar" del plugin "org.gvsig.editing".  Tu usuario se instala tu plugin
y al hacerlo actualiza la libreria del otro. Unas semanas mas tarde
aparece una actualizacion del plugin de "org.gvsig.editing", y el usuario
se actualiza el plugin. Al hacerlo reemplaza la libreia "AAA.jar" que
tu sustituiste por la original, y con ello tu plugin deja de tener la
funcionalidad que añadiste dejando de funcionar.

Bueno, de momento el usuario se queda sin tu plugin... pero... va y se
le ocurre intentar reinstalar tu plugin. Y, Oh! vuelve a funcionar, ya
que vuelves a sustituir la libreria "AAA.jar". Pero de repente, las
mejoras que habian llevado a precisar la salida de una actualizacion
de "org.gvsig.editing" han desaparecido... o puede ser peor aun, que
el plugin "org.gvsig.editing" ya no arranca por que tu libreria no tiene
alguna clase que se habia introducido con la actualizacion.

Vamos, que el usuario tiene que decidir entre tener instalado tu plugin
o cualquier version mas nueva que la que tu tenias del plugin "org.gvsig.editing".

Para evitar todo esto, siempre que puedas, no modifiques nada que este
fuera de tu plugin. Si necesitas nueva funcionalidad para tu plugin
metela dentro de el, en su propia libreria.

De hecho, si quisieses que tu plugin luego tuviese la "etiqueta" de "oficial"
no deberia modificar cosas que esten fuera de su plugin, para evitar
conflictos entre versiones de estos.

Otra cosa es que la libreria a la que quieras añadir la funcionalidad este
en tu plugin. En este caso, mi recomendacion es...

- Si la nueva funcionalidad es una funcionalidad que es un subconjunto o
  superconjunto de la funcionalidad que hay en la libreria que quieres
  ampliar, puedes meterla dentro.

- Si la funcionalidad no tiene nada que ver con la que hay en la libreria
  que quieres ampliar crea una nueva.

Y tanto en un caso como en otro, intenta que no disgregues la funcionalidad
en muchas librerias con apenas funcionaldad o incluyas en una libreria
"gigante" muchas funcionalidades dispares. Intenta mantener un equilibrio
y refactorizar cuando veas que crece demasiado o que lo disgregas demasiado.

Si apesar de lo que te comento, se precisa modificar una libreria de otro
plugin, lo que recomiendo es que te pongas en contacto con el responsable
de la libreria y si se consideran interesante los cambios que propones
los suministres en forma de parches para que se introduzcan en la siguiente
distribucion de la misma.

Sobre lo otro que preguntas... ¿ cual es la forma mas adecuada para intalar
un plugin ?

Pues lo adecuado es generar un paquete para tu plugin.
La version 2, dispone de un administrador de complementos en la que el usuario
puede seleccionar que complementos, principalmente plugins, quiere instalar.
Estos pueden instalarse desde:

- Un fichero en disco con el paquete de instalacion. Normalmente seria el
  caso en el que tu envias al usuario el paquete de tu plugin (o lo cuelgas
  en la web para que se lo descargue).

- Puedes pasarlo al proyecto gvSIG para que lo incluyan en el repo de complementos
  y este disponible para todos los usuarios.

- Podrias crear tu propio repo de complementos y enviar al usuario el enlace a tu repo
  (esto seria lo mas complicado ya que no hemos generado aun doc de como hacerlo).

El administrador de complementos se porto a la 1.11  y luego a la 1.12, sin embargo
el de la 1.11 estaba en sus primeros estados y aun estaba muy verde.

Una vez tenemos claro que la forma de instalar plugins es generar un paquete
de gvsig para el, la cuestion es como lo generamos. Con la distribucion de gvSIG
tenemos una herramienta para generar paquetes de plugins ya instalados. Es responsabilidad
del desarrollador desplegarlo sobre una instalacion de gvSIG, bien manualmente o
a traves de algun script de ant o maven, y una vez alli usar la herramienta para
generar el paquete. Por defecto esa herramienta no viene activada, habra que ir a
preferencias y activar la extension:

org.gvsig.installer.app.extension.creation.MakePluginPackageExtension

Y tras reiniciar gvSIG tendremos en el menu herramientas una opcion para generar
los paquetes para nuestros plugins.


Resumiendo, como reglas generales:

- No actualizar librerias de otros plugins.

- Mantener la funcionalidad cada cual en su libreria.

- Ponte en contacto con el responsable de una libreria cuando quieras
  añadir nueva funcionalidad a esta.

- Usa el administrador de complementos para instalar tus plugins.

En general, son ideas, si vas a poner en practica alguna pregunta...
y se paciente, no siempre podemos contestar todo lo rapido que nos guataria.

Un saludo
Joaquin


> 
> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/Buenas-practicas-para-la-instalacion-de-extensiones-tp5053087.html
> Sent from the gvSIG desarrolladores mailing list archive at Nabble.com.
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
> 


-- 
--------------------------------------
Joaquin Jose del Cerro
Development and software arquitecture manager.
jjdelcerro en gvsig.com
gvSIG Association
www.gvsig.com
www.gvsig.org


Más información sobre la lista de distribución gvSIG_desarrolladores