The Tools library is an important part of gvSIG. It provides a number of utilities and services which support the other modules in gvSIG. The main functionality provided by this library relates to:

• Registration of extension points
• Initialisation of libraries
• Utilities for the separation of the API and implementation (Registration of APIs, registration of implementations for the APIs, registration of SPI service providers or localisation of an API implementation)
• Monitoring of Tasks

Although these are the most important services the library provides, it also provides other tools that can be considered structural to the application. These include:

• Disposables
• Interfaces for managing Observers-observables
• Interfaces for managing visitors
• Definition of data types
• Base interfaces for evaluators
• Object Persistence

We will focus now on three basic concepts that are repeated throughout the code that we see, and that are linked to utilities that enable a strict separation of the API from the implementation:

• Libraries. These are pieces of code normally associated with a jar that provides a functionality. Each of these libraries must be a class that implements the Library interface, usually extending the AbstractLibrary class. They have methods for initialising the library that are invoked when it is loaded.
• Managers. These components provide functionality to the application, acting as an agent for the various services offered by the library and for their configuration. Acts as a singleton, since in the application there is usually only one instance of each of these components. Libraries will have one or more of these according to their logic.
• Locators. This is a utility that allows you to register implementations of managers for a given library, and to retrieve the manager implementation of a specific API.

These three components play a major role whenever we want to use or create new components, as they are the devices that allow us to access different parts of gvSIG

The Andami framework is used to compose the gvSIG application. It provides mainly two types of services, the management and loading of plugins, and the management of windows that make up the user interface.

At this point we will focus briefly on the management of plugins. Andami provides a launcher for the application that initializes the plugins system, and is responsible for loading the plugins that are installed in the application. A plugin is a functional unit that can provide:

• Menu options to install the application
• New buttons and toolbars
• New data providers
• New document types

Normally in a gvSIG installation you will find a folder gvSIG/extensions. This folder contains the different plugins installed in the application. Each plugin is contained in a folder, which always contains the files:

• Config.xml, which describes:

  • Where to find this plugin's classes

    Tip

    More information on the structure and different labels that are allowed in this file can be found at config.xml file

  • Whether this plugin depends on some other plugin

  • What menu options the plugin added to the application

  • What toolbars and buttons the plugin added.

• Package.info, which reports on the version, name, ID or description of the plugin. It is like a container for the plugin's metadata, and allows us to identify the plugin when updating or reinstalling it.

There is also a theme folder, which contains the configuration of the application's splash, window icons and background colors.

Although the mechanism for adding new functionality to gvSIG is also adding new plugins, these in turn contain one or more extensions that provide the functionality being added. So we will have a plugin containing extensions.

With respect to the management of plugins, the main components are:

• PluginsLocator, which provides access to the plugins manager through a static getManager method.
• PluginsManager, which provides methods to interrogate which plugins are loaded and what extension each of them has.
• The PluginsServices class that represents an instance of a given plugin.
• The IExtension interface that represents an action or block of actions to incorporate into gvSIG.
• The ExclusiveUIExtension interface that allows us to control the visibility of all the extensions loaded into the application.

We will examine the IExtension interface in more detail. This is the interface that we implement in order to add a new button or menu option. In this interface we find the methods:

• Initialize. Executed when loading the extension and initialising the plugin. Keep in mind that when you invoke this method it is possible that not all the gvSIG extensions will have been loaded and initialized. Normally here we will initialise the components of our extension that are used by other extensions.
• postInitilize. Invoked in the indexing of the extension. Just after having invoked the initialize method of all the gvSIG extensions. Normally, here we will perform the initialisation of our extension's components that require other extensions.
• terminate. Invoked when gvSIG needs to release the extension. Normally this will occur when the application is closed. Here we ensure that the system resources reserved for our extension are released.
• execute. This method is executed every time the user interacts with the menu or toolbar button associated with the extension. Normally this will implement the execution of our functionality.
• isEnable. Invoked when you need to know if the user interface associated with the extension (buttons or menu items) is enabled.
• isVisible. Is invoked when you need to know if the user interface associated with the extension (buttons or menu options) is visible.

Andami, in addition to providing a mechanism for loading and managing plugins, also provides an API for the management of the application's windows. Currently the MDI paradigm is used to manage windows. However, gvSIG's window manager itself can be replaced to provide other forms of display (SDI, tabs,...).

The main entities found in Andami related to windows management are:

• MDIManagerFactory is the factory where it is recorded and from which we obtain the instance of MDIManager (made from Locator).
• MDIManager represents the window manager registered in gvSIG. It has methods to make or close a window.
• IWindow is the interface that must implement a JPanel to be present as a window in gvSIG.
• WindowInfo, provides our panel through the IWindow interface and defines the characteristics of our window (title, size, type,...).

In general if we do not need fine control over our windows we can use the ShowWindow method from MDIManager to display a window from a standard JPanel swing.

In gvSIG there are a number of plugins that provide the application's base functionality that have some relevance to the other plugins. These are:

• org.gvsig.app. This plugin provides gvSIG with the bulk of the generic functionality of the application, as well as basic access to vector data. It provides:

  • The concept of project and its documents.
  • The View document.
  • The Table document.
  • The Map document.
  • The basic tools for accessing the view's vector data.

  This plugin, in addition to implementing these features, provides a manager and an important locator in order to develop other plugins:

  • ApplicationManager. This is a manager that provides access to the application's other managers, as well as basic functionality for accessing the global resources of the application. This becomes the object representing the gvSIG application.
  • ApplicationLocator, which is the locator that gives us access to the manager of the application (ApplicationManager).

• org.gvsig.editing provides the functionality for editing tabular and vector data.

• org.gvsig.geodb adds support for accessing databases such as PostgreSQL.

• org.gvsig.i18n.extension adds support for internationalization of the application.

• org.gvsig.crs.extension adds support for management of CRSs.

• org.gvsig.rastertools adds raster support to gvSIG.

• org.gvsig.app.extension adds support for managing add-ons.

• org.gvsig.app.daltransform adds support for registration and implementation of transformations on data.

These are some of the most important plugins in gvSIG in the sense that they provide important basic functionality necessary for other plugins to function.

Besides these plugins there are many more plugins in the gvSIG distribution that may or may not be necessary depending on what we're going to do with gvSIG.

When developing with gvSIG it is useful to know the existing plugins, especially the functionality provided by the ApplicationManager. But the important thing is to control which of the libraries we will require in order to implement the functionality we need.

In version 2.0.0 of gvSIG major changes have been introduced, both in how to build gvSIG as well as in the nomenclature used to identify the projects and libraries that are generated. However, this is not a process that has taken place suddenly, it has been happening over a number of years. This has now resulted in a lack of uniformity in the nomenclature of existing components. When it comes to referring to a library we can use the Eclipse project name, the name of the generated jar, or the Maven artifact name. In projects generated recently the chosen rule is that these three names must match, with the name of the Maven artifact being used for all three. Prior to this decision projects had different names for each of these components. For a developer who intends using gvSIG, the important thing is to know the names of the Maven artifact, since they usually need to know for which artifacts dependencies should be set, with the eclipse project name associated with that artifact being less relevant.

The libraries that most meet our needs in gvSIG are:

• org.gvsig.tools.lib contains structural utilities. Already mentioned at the beginning of the document so we won't elaborate on it at this point.
• org.gvsig.fmap.geometry (libFMap_geometries). The library for managing gvSIG's geometries. Presents a geometry model with an API independent of its implementation.
• org.gvsig.projection (libProjection). The library for managing gvSIG's coordinate reference systems.
• org.gvsig.fmap.dal (libFMap_DAL). The data access library of gvSIG (Data Access Library). It is used by all projects in one form or another to access to a shape, dxf, a PostgreSQL table, a GML, a WFS layer or a DGN file. It presents a common API for accessing vector and tabular data or for accessing coverages.
• org.gvsig.fmap.mapcontext (libFMap_mapcontext). Contains the API and implementation of layers and map at the logical level.
• org.gvsig.fmap.control (libFMap_controls). Contains swing components that are linked to the logical components that are presented in the DAL library and mapcontext. It could be a visual component for displaying a map or presenting a table obtained from the DAL.
• org.gvsig.crs (libJCRS). Is an API implementation of the projections from org.gvsig.projection.
• org.gvsig.symbology.lib.api. Contains the API of gvSIG's symbology library.
• org.gvsig.ui (libUIComponent). This is a library that houses a series of general utility graphical components.