[Gvsig_desarrolladores] Como descargar y compilar gvSIG 2.1.0

[Jorge Gaspar Sanz Salinas]

El 17/12/14 a las 10:13, Joaquin Jose del Cerro Murciano escribió:
>
>
> El 16 de diciembre de 2014, 16:24, Alonso Morilla
> <almorillam en gmail.com <mailto:almorillam en gmail.com>> escribió:
>
>     Muchísimas gracias, Joaquín.
>
>     Después de compilar intentaré ir buscando las diferentes
>     extensiones para
>     armar una distribución entera.
>
>
> Hola, 
> Compilar gvSIG como ejercicio, esta bien; pero no debería hacerse como
> norma.
> gvSIG 2.1 esta pensado para ser modular y poderse personalizar desde
> tu plugin, sin necesitar compilarlo.
> Es una mala practica personalizar gvSIG a partir de modificar sus
> fuentes, compilarlos y generar tu distribución (hay otros mecanismos
> para personalizar tu distribución). Lo normal es que si haces eso las
> cosas dejen de irte en la siguiente distribución de gvSIG...
>
> Si necesitas añadir algo a gvSIG que no puedes añadir desde tu plugin,
> lo acertado seria que lo comentes y veamos la mejor forma de añadirlo
> o añadir opciones para que lo puedas hacer, sin que te descuelgues de
> gvSIG en la siguiente revisión.
>  
> Por ejemplo, supongamos que tenemos el plugin:
>  
> - org.gvsig.app.mainplugin-2.1.0-final
>  
> En el que esta codificado el documento vista, y lo retocas para
> añadirle una nueva funcionalidad. Con tus retoques generas una versión
> del plugin:
>  
> - org.gvsig.app.mainplugin-2.1.0-Personalizado
>  
> En un momento dado aparecen errores y son corregidos en la versión
> oficial del plugin, y se genera la versión:
>  
> - org.gvsig.app.mainplugin-2.1.1-final
>  
> Si un usuario de tu versión personalizada quiere optar a las mejoras
> tendrá que decidir entre estas o las de tu plugin, ya que no puede
> tener las dos simultáneamente. Lo normal es que en un momento dado
> decidas que te vendrían bien esas mejoras y entonces decidas que vas a
> coger el código de esta ultima versión y metes en el tus cambios y
> generas una nueva versión de tu plugin:
>  
> - org.gvsig.app.mainplugin-2.1.1- Personalizado
>   
> De esta forma estas obligado a que cada vez que aparecen cambios en la
> versión oficial, los usuarios de tu personalización o dejan de usar la
> personalización o tienes que realizar una labor de desarrollo para
> incluir esos cambios en tu versión.
>  
> Nosotros mismos dentro del proyecto hemos caído en esto en alguna
> ocasión antes de darnos cuenta que no es viable trabajar así.
> La personalización no se debería hacer tocando los fuentes de gvSIG,
> si no aportando un plugin nuevo que incluya las mejoras. Y para
> hacerlo no deberías necesitar o depender de los fuentes de gvSIG, solo
> de los tuyos.
>  
> Entiendo, que dada la falta de documentación de desarrollo, puede ser
> practico tener a mano los fuentes y ver como se hacen algunas cosas
> para saber que puedes usar y como hacerlo, pero no deberían
> modificarse; o por lo menos no sin devolver las modificaciones al
> proyecto para no tener que mantener un fork.
>  
> En el software libre es corriente hablar de forks. 
> Hay gente que mide lo exitoso de un proyecto por el numero de forks
> que tiene.
> Sin embargo esto es muy engañoso. Cuando usas una herramienta lo que
> persigues es que te quite trabajo, no que te de mas, y mantener un
> fork actualizado requiere esfuerzos considerables, por no hablar que
> tus mejoras o cambios no revierten de nuevo a la comunidad gvSIG.
>  
> Resumiendo...
> Puedes descargarte y compilar gvSIG, esa es la gran diferencia con
> respecto a usar un software de terceros privativo, pero si precisas
> añadirle funcionalidad, lo suyo es que lo hagas creando tus propios
> plugins independientes. A pesar de que al principio parezca mas rápido
> tocar el código aquí y allá, recompilar y listo; a medio plazo te
> ahorrara tiempo personalizar desde tu plugin. 
> Si tienes que aprender a hacer cosas con gvSIG, aprende como hacer tus
> propios plugins sin tocar el código base de gvSIG (que siempre tendrás
> ahí para mirarlo y copiarlo cuando lo necesites).
>  
> Y si a pesar de querer meter tus cambios en tu plugin te ves obligado
> ha hacer un fork, intenta hacerlo siempre del pedazo mas pequeño
> posible, si puede ser solo de un plugin mejor que de dos, y coméntalo
> con los responsables de esos módulos o por la lista de desarrollo
> directamente, para intentar que tenga el menor impacto en los usuario
> el sustituir un plugin por otro.
>  
> Uuuuffff
>  
> Dicho todo esto, que la gente no suele entender...
> Si necesitas ayuda para compilar/modificar gvSIG o tus plugins solo
> has de pedirla, si puedo procuro intentar ayudar.
>  
> Un saludo
> joaquin
>  

Muchas gracias Joaquín por tomarte tu tiempo en explicar esto con
detalle. Este tema que para muchos puede resultar evidente, no lo es
tanto para la gente que viene de desarrollar la 1.x, y es importante
cambiar esa ¿mala práctica? para conseguir que la comunidad desarrolle
componentes que "resistan" cambios de versión o actualizaciones en los
plugins.

La verdad es que el cambio a maven y tener los fuentes en los jars, sin
necesidad siquiera de tener todo gvSIG montado en el IDE ha sido clave
para este cambio. Fue un esfuerzo *enorme* por parte del equipo de
arquitectura de gvSIG y hay que agradecerlo y aprovecharlo al máximo.

Saludos.


-- 
Jorge Gaspar Sanz Salinas
gvSIG Team at Prodevelop
http://www.gvsig.org
http://www.gvsig.com

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20141217/0354ca84/attachment.htm