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@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. jjdelce...@gvsig.com gvSIG Association www.gvsig.com www.gvsig.org _______________________________________________ gvSIG_desarrolladores mailing list gvSIG_desarrolladores@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
