Apuntes del taller GvSIG 2.0

Estos son los apuntes que tomé sobre gvSIG 2.0 en las últimas Jornadas GvSIG.

Pre-requisitos:

  • Java
  • Eclipse
  • Ant (preferiblemente)
  • Maven (preferiblemente)
  • gvSIG (esto es recursivo :))

La principal ventaja de gvSIG 2.0 es que puedes crear un plugin sin saber cómo funciona gvSIG ni tener que compilarlo. Tenemos una instalación de gvSIG que despliega unos binarios que genera el workspace. Pero no tenemos que tocar los fuentes de gvSIG, salvo que algo no funcione (bugs) o haya que añadir alguna funcionalidad al núcleo. Preferentemente no lo toques, mejor consulta con los desarrolladores del núcleo de gvSIG y ellos intentarán encargarse.

This are the notes that I took over gvSIG 2.0 on the latests Jornadas GvSIG.

Pre-requisites:

  • Java
  • Eclipse
  • Ant (should)
  • Maven (should)
  • gvSIG (this is recursive :))

The main advantage of gvSIG 2.0 is that you can create a new plugin without knowing how does gvSIG work or having to compile it. We already have a gvSIG installation that deploys the binaries to the workspace. But we don’t have to change the source code of gvSIG, unless something doesn’t work (bugs) or we have to add some new functionality to the core. Better if you don’t touch it,ask the gvSIG developers and they will take care.

 Con el binario de gvSIG viene un asistente para ejecutarlo y que cree un workspace de eclipse con una plantilla prefijada que deja todo configurado para compilar nuestra extensión. También incorpora un asistente para generar instalables fácilmente. Estos asistentes son accesibles mediante la aplicación gvSIG, en el menú de la aplicación.

La librería org.gvsig.tools es la infraestructura básica para desarrollar plugins. La principal funcionalidad se centra en registro de puntos de extensión, utilidades para separar API, implementaciones y SPI (proveedor de servicios), así como monitorización de tareas (que en la versión 1.0 solía congelar la aplicación). Esta librería también soporta eventos, persistencia, etc…

Una librería es un jar. Cuando nuestra aplicación levante el jar, org.gvsig.tools prepara dicha librería y la inicializa dentro del core de gvSIG. Las clases dentro de la librería implementan la interfaz Library (AbstractLibrary).

Los managers (PluginsManager) son el punto de entrada a las funcionalidades. Son como factorías (singletons) (al menos uno por librería) que levanta instancias de las funcionalidades incluídas dentro de la librería. También guarda la configuración del módulo.

Los locators (PluginsLocator) permiten registrar implementaciones de managers. Nos permiten recuperar la implementación de manager de un API en concreto. “Dame el manager de esta librería.”

Un plugin es una pieza que aporta una funcionalidad: botones y barras de herramientas, opciones de menús, proveedores de datos y tipos de documentos. Andami no ha evolucionado demasiado desde la versión gvSIG 1.x. Andami es el framework de los plugins.

El plugin siempre tendrá al menos dos ficheros:

  • config.xml que indica las clases que implementan el plugin, las dependencias y los menús
  • package.info que indica la versión, el nombre, el build,… del plugin.

Una extensión (IExtension) es un conjunto de herramientas asociadas a un plugin metidas en una barra de herramientas o menú y funcionan de forma conjunta. Un grupo de plugins, vaya. La extensión que implemente ExclusiveUIExtension especifica qué herramientas están o no visibles en cada momento, sin tener que tocar código en el core de gvSIG.

Para crear un nuevo plugin, hacemos uso de la herramienta del menú de generación de plugins disponible en la versión de desarrollo de gvSIG. Esto genera el workspace automáticamente e instala dicho plugin en el gvSIG desde el que hemos generado el plugin. Si no tienes versión de desarrollo, tendrás que compilar gvSIG de los fuentes.

Conviene ir haciéndolo mientras se leen estos apuntes o puedes perderte.

El plugin constará de dos proyectos maven: org.gvsig.plugin y org.gvsig.plugin.app. org.gvsig.plugin aportará la funcionalidad de la librería de forma independiente de gvSIG (la lógica de negocio). Puede tener dependencias de librerías de gvSIG, pero debería poder funcionar sin tener que abrir la aplicación. Es decir, no requiere nada de Andami, por ejemplo. En org.gvsig.plugin.app.mainplugin (dentro de org.gvsig.plugin.app) tendrá la implementación de dicha funcionalidad dentro de gvSIG.

Lo suyo sería que los paquetes que ponen “api” contengan interfaces y que los paquetes que contienen “impl” tengan clases con la funcionalidad.

En principio el workspace está preparado para trabajar con eclipse e importar los proyectos con el plugin de maven. Si hemos cogido una plantilla adecuada al generar los fuentes del plugin, tendremos prácticamente todo el trabajo hecho (salvo la lógica de negocio exacta de nuestro plugin).

Es importante hacerse un proyecto java para probar nuestro plugin, con su propio main, sin tener que arrancar gvSIG. Así mismo se recomienda que en la parte de librería haya tests unitarios. Es decir, podemos hacer una aplicación con toda la potencia de gvSIG, pero sin utilizar gvSIG en sí, es decir, como si gvSIG fuera una potente librería gis. Conclusión: si lo hacemos bien, podríamos incluso utilizar nuestro plugin de gvSIG en otra aplicación… como Gofleet.

Cada plugin tiene su propio instalador, que también se genera con un asistente dentro de la aplicación gvSIG.

With the binary, there is a wizard which creates an Eclipse workspace with a default template that leaves all set up but to compile our extension. It also includes a wizard to easily generate installables. These wizards are accessible through the gvSIG application, at the application menu.

Org.gvsig.tools is the basic infrastructure library to develop plugins.The main functionality is focused on the registration of extension points, utilities to separate API, implementations, SPI (service provider), and monitoring tasks (which in version 1.0 used to freeze the application).This library also supports events, persistence, etc …

A library is a jar. When our application contains the jar, org.gvsig.tools prepares and initializes this library within the core of gvSIG. The classes in the library implement the interface Library (AbstractLibrary).

The managers (PluginsManager) is the entry point of the features. They are like factories (singletons) (at least one per library) that raises the request of the functionality included in the library. It also saves the configuration of the module.

The locators (PluginsLocator) allow to register implementations of managers.We can recover a specific manager API. “Give me the manager of this library.”

A Plugin is a piece that adds a functionality: buttons and toolbars, menu options, data providers and types of documents. Andami has not evolved much since the gvSIG version 1.x. Andami is the framework for the plugins.

The plugin will always have at least two files:

  • config.xml indicating the classes that implement the plug-in units and menus
  • package.info indicating the version, name, build, … of the plugin.

An extension (IExtension) is a set of tools associated with a plugin inside a toolbar or menu and they work together. A group of plugins, you may say. The extension that implements ExclusiveUIExtension specify what tools are or not visible, without touching the core code in gvSIG.

To create a new plugin, we make use of the tool menu generation of plugins available from the development version of gvSIG. This generates the workspace automatically and installs the plugin on the gvSIG from which we generated the plugin. If you have no development release of gvSIG, you will have to compile the sources.

You should be starting a plugin with the wizard while reading this notes or you will be lost.

The plugin consists of two maven projects: org.gvsig.plugin and org.gvsig.plugin.app. org.gvsig.plugin provide the functionality of the library independently of gvSIG (business logic). May have library dependencies on gvSIG, but should be able to operate without having to open the application. That is, it requires nothing of Andami, for example. In org.gvsig.plugin.app.mainplugin (within org.gvsig.plugin.app) we will implement the gvSIG functionality.

The “api” packages should contain interfaces and the “impl” packages should contain implementations.

The workspace is ready to work with Eclipse if we import the project with the maven plugin. If we took an appropriate template to generate the plugin sources, almost all the work is done (except for the exact business logic of our plugin).

It is important to have a java project to test our plugin with its own main, without having to start gvSIG. Also it is recommended that the library has unit tests. That is, we can make an application with the full power of gvSIG, but without using gvSIG itself, ie as if gvSIG were a powerful library GIS. Conclusion: if we do well, we could even use our plugin into another no gvSIG application … as Gofleet.

Each plugin has its own installer, which also is created by wizard inside the gvSIG application.

Un comentario en “Apuntes del taller GvSIG 2.0”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *