[Gvsig_desarrolladores] Entorno de compilación y depuración de gvSIG

[Luis W. Sevilla]

Hace un par de semanas estuve preparando unas instrucciones básicas
sobre como empezar a ejecutar gvSIG a partir de la distribucion en
fuente. Salvo error en mis notas, el conjunto de acciones era algo así como:

Pasos seguidos para poner en marcha el desarrollo con gvSIG:

          o

            tener bajado Java JDK 1.4.2 o superior, JAI y java image I/O

          o

            bajar Eclipse (e instalarlo).

          o

            Bajar los fuentes de gvSIG

          o

            abrir eclipse, y abrir como workspace el directorio de los
            fuentes.

          o

            leer el fichero leeme.txt que hay en el directorio de los
            fuentes (workspace)

          o

            Activar la opción 'compilar automáticamente': Run->Build
            Automatically

          o

            En el proyecto appgvSIG, sobre el fichero llamado
            'build.xml' dar botón derecho->Run As->Ant Build...; en la
            pestaña 'targets' que sale, seleccionar el target
            'build-all' solamente. Y pulsar el botón 'Run'

          o

            F5 (Actualizar) en _fwAndami

          o

            clean y build en los proyectos que quedan con error
            (extGeoprocessing)

          o

            de nuevo el build de appgvSIG

          o

            en _fwAndami, en com.iver.andami.Launcher, boton derecho y
            Run As ... 'Java Aplication'

          o

            Ya estamos ejecutando gvSIG; en el botón verde (Run), ha
            aparecido 'gvSIG'

Además, recordar que eclipse dispone de dos maneras de 'simplificar' un
workspace:
    - los 'Working Sets' (seleccionables en la solapa 'Package
Explorer'. Sirven para mostrar en esa ventana solo los proyectos que nos
interesan, ocultando los demás.
    - La opción 'close project'. Sirve para hacer que un proyecto deje
de estar activo. Casi como si lo hubieramos borrado.
Usando estos dos recursos, y sin necesidad de hacer un workspace nuevo,
podemos 'enfrentarnos' a una parte reducida de gvSIG, e ir ampliando a
medida que vayamos necesitando más.

    Saludos
       Luis

Francisco José wrote:

> Sí, todavía se puede.
>
> Internamente, lo que hace Eclipse cuando depuras paso a paso y te
> metes dentro de un .jar, es escribir en el fichero .classpath líneas
> como éstas:
>
> <classpathentry sourcepath="/libGDBMS"
> path="/libFMap/lib/gdbms-0.8-SNAPSHOT.jar" kind="lib"/>
>    <classpathentry path="/_fwAndami/lib/castor-0.9.5.3-xml.jar"
> kind="lib"/>
>    <classpathentry sourcepath="/Utiles/src"
> path="/_fwAndami/lib/iver-utiles.jar" kind="lib"/>
>
> Las mete cuando te pregunta que dónde está el código fuente de tal o
> cual librería, y a partir de ahí, puedes depurar paso a paso esa
> librería, e incluso cambiar el código
> fuente sin tener que recompilar. Eso sí, cuando paras la ejecución,
> tendrás que recompilar con los ant para que esos cambios se tengan en
> cuenta en la siguiente ejecución.
>
> Salu2 y suerte.
>
> Miguel R. Luaces escribió:
>
>> Hola,
>>
>> me gusta mucho tú idea, Francisco José. ¿Se puede hacer así todavía?
>> Como he visto que la mayor parte del código se gvSIG se carga como
>> plugin (empezando por corePlugin o appGVSIG, por ejemplo), no tengo
>> muy claro si va a ser posible poner breakpoints en esas clases y que
>> Eclipse las encuentre y pare.
>>
>> Yo ahora mismo estaba empezando a intentarlo por ese camino que tú
>> indicas, pero no sabía si tendría éxito. Si me dices que sí que
>> funciona, pues sigo por ese camino.
>>
>> Gracias. Un saludo,
>>  Miguel
>>
>> On 12/28/06, Francisco José <fpenarru en iver.es> wrote:
>>
>>> Nosotros lo tenemos en el CVS, y bajando del CVS los proyectos
>>> principales, todo está prácticamente configurado. Solo necesitas usar
>>> los build.xml de cada proyecto para ir compilando lo que necesitas.
>>> Y cuando cambias algo, vuelves a compilar.
>>>
>>> Ahora bien, quizás lo más cómodo sería hacer algo como lo que hice yo
>>> hace algún tiempo:
>>> 1.- Creas un workspace nuevo vacío.
>>> 2.- Importas todos los proyectos que necesites (para hacer
>>> prácticas, lo
>>> mejor es no apabullar y coger lo mínimo: Andami, corePlugin, FMap,
>>> gvSIG
>>> (si vas a operar con raster, también Cresques).
>>> 3.- Configuras todo lo que se te ocurra. Para ello, pones las opciones
>>> de compilación (1.4 o superior), pones los parámetros para ejecutar
>>> gvSIG (launcher de Andami), etc, etc.
>>>
>>> Una vez arrancado gvSIG desde Eclipse, ya lo tienes todo configurado.
>>> Basta copiar ese directorio a otros ordenadores, y decirle a los
>>> estudiantes que al abrir Eclipse, abran ese workspace.
>>>
>>> Muy recomendable: Una vez ejecutado gvSIG la primera vez, ejecuta en
>>> modo Debug y pon algunos breakpoints en appGvSIG, en FMap y/o en
>>> corePlugin y Andami. Los pruebas, y te pedirá que le digas qué
>>> proyectos
>>> tiene que tener en cuenta para buscar el código fuente en
>>> depuración. Se
>>> lo dices, y tendrás todo preparado para debuggear, e incluso podrás
>>> cambiar "al vuelo" trozos de código, salvar el archivo y continuar con
>>> la ejecución, probando los cambios que hayas hecho. Utilísimo para
>>> programar.
>>>
>>> Espero haberte ayudado.
>>>
>>> Salu2.
>>>
>>> Miguel R. Luaces escribió:
>>> > Hola,
>>> >
>>> > como parte de la asignatura "Bases de Datos 3" de la Facultad de
>>> > Informática de la Universidad de A Coruña tenemos un mes de clase
>>> > dedicado a Sistemas de Información Geográfica (SIG).
>>> >
>>> > A los alumnos les proponemos como práctica la implementación de
>>> alguna
>>> > funcionalidad relacionada con SIG, ya sea a nivel de base de datos
>>> > (mediante Pl/pgSQL), a nivel de servicios web, o a nivel de
>>> > herramientas de visualización.
>>> >
>>> > Mi idea este año era hacerlo con gvSIG. Sin embargo, es bastante
>>> > difícil ponerlo a funcionar en Eclipse de tal forma que se pueda
>>> > compilar una nueva extensión, modificar alguna funcionalidad, o
>>> > utilizar las herramientas de depuración o las de lectura de codigo.
>>> > Mientras que con una herramienta como JUMP puedo montar un
>>> proyecto de
>>> > Eclipse en cinco minutos que permita desarrollar y depurar
>>> > extensiones, y que incluso permite cambiar clases de JUMP, poner
>>> > breakpoints, inspeccionar variables, etc..., llevo dos días
>>> > intentándolo con gvSIG y aún no lo he conseguido del todo.
>>> >
>>> > Así que la pregunta es: ¿como lo haceis vosotros? ¿Habeis conseguido
>>> > montar gvSIG en Eclipse de tal manera que se puedan desarrollar
>>> > extensiones fácilmente, poniendo breakpoints en cualquier clase? Mi
>>> > solución ideal sería en la que pudiera tener gvSIG en un único
>>> > proyecto, que Eclipse compilara las clases para poder detectar los
>>> > errores en el entorno y no tener que detectarlos al compilar con ant,
>>> > y en la que no tuviera que asociar a mano con cada uno de los jars de
>>> > las librerias y las extensiones un directorio de codigo fuente.
>>> >
>>> > Muchísimas gracias por adelantado por las ideas que me propongais.
>>> >
>>> > Un saludo,
>>> >  Miguel
>>> >
>>> >
>>> > _______________________________________________
>>> > gvSIG_desarrolladores mailing list
>>> > gvSIG_desarrolladores en runas.cap.gva.es
>>> > http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
>>>
>>>
>>> -- 
>>> Francisco José Peñarrubia
>>> Equipo gvSIG
>>>
>>> IVER T.I. S.A.
>>> c/Salamanca 50
>>> 46005 Valencia
>>> Spain
>>


-- 
  Luis W. Sevilla
  Responsable de desarrollo gvSIG en la / gvSIG development Chief at
  Conselleria de Infraestructuras y Transporte
  Generalitat Valenciana
  Valencia - Spain
  http://www.gvsig.gva.es