Contributions and patches to the gvSIG code

Version: 1.2

Scope of this document

This document aims to give guidance on the steps to follow to make changes to the existing code in gvSIG.

The contributions to the gvSIG code are mainly divided into three types:

  1. Bugs. Bug fixes in the existing feature in gvSIG.
  2. Improvement of a feature finishing. They are small improvements on existing feature in gvSIG.
  3. New features. Contribution of new feature or modifications to existing code to develop new feature externally.

Since these three ways to contribute to the gvSIG code do not follow exactly the same channels and procedures, we will describe them separately.

A common theme to the forms to contribute to the gvSIG code is that you must surrender the authorship rights of the code contribution to the gvSIG project, as described in the documents What is the gvSIG CLA? and the Contributor License Agreement.

Exclusions

This document does not cover the requirements to be met by a project that provides a new plugin to gvSIG, for this we recommend you to consult the Official gvSIG Projects.

Bugs

If you have detected a bug in the application and have implemented to correct code to fix it, you can contribute it to the project so this is included in future versions of the application.

Not always all corrections will be accepted, sometimes for a lack of resources for inclusion in the review, others for disagreements over whether that implementation is adequate or not to correct the bug. Keep in mind that sometimes the correction of a small bug can give rise to unwanted effects in other parts of the application.

You must complete two tasks to make corrections and fix a bug:

Important

If the code modification is proposed by a user with permission to commit, it will not be necessary to attach a patch, instead simply leave a comment with the review number that applies to the change.

It is also advisable to review the document What should I do to fix a bug?.

Before you upload changes, you must wait until your ticket is approved and assigned.

This means that for all corrections a ticket should be registered, approved and allocated.

Remember that the gvSIG project resources are limited and we can not always act immediately on the tickets received. We will try to respond as soon as possible.

Improvements in a feature finishing

We understand that sometimes there are a number of small changes that although they are not considered errors or bugs; it would be good that they are made on gvSIG. They can be as simple as changing the default option of a dropdown menus or the position of a menu option which it seems more logical somewhere else. They are not errors as such because the application works as designed. They are really small improvements in the existing feature.

The steps to follow to make such amendments to the code will be similar to those to be followed during the contribution of code for a bug, with the only exception that instead of using the gvSIG bug registry it should be used the New request for features .

New Features

When implementing a new feature in gvSIG it must be noted that, in general, new features are incorporated in the form of new plugins, so from the user point of view to add a new feature does not normally requires going through this process. The simplest way is to add the new feature to the unofficial gvSIG catalogue or to follow the procedures described in Official gvSIG Projects so it is included as an official project.

So ... When do we follow these procedures?

We should apply this procedure when in order to add our feature we have to modify parts of gvSIG, usually adding new extension points. The features from the user point of view will be kept in a separate plugin, and the necessary changes will be introduced in gvSIG so the plugin works as designed.

To provide sufficient code to gvSIG that would allow us to develop our plugin, we should request it through the tracker in New request for features. There we will register a ticket with a description of what we want to do, attaching the code as a patch or patches, with the implementation of it.

Before we develop our feature we should register the ticket, describing:

In the ticket you must mark in the Has patch field a yes so that development team clearly identifies the ticket as a request for feature that aims to provide code to gvSIG.

Note that:

Once the petition is read, you can be requested to provide more information or to make some changes in some part of what it claims to do, and finally, to be asked for the code that implements it, as a patch or patches, to be attached to the ticket.

Important

If the code modification is proposed by a user with permission to commit, it will not be necessary to attach a patch, instead simply leave a comment with the review number that applies to the change.

Before you upload changes, you must wait until your ticket is approved and assigned.

Remember, the first time you must send us the document with the CLA surrendering your copyright on the code that you are giving to gvSIG. More information about this can be found in the Contributor License Agreement document.

Change registry
version Description
1.1 (translation pending) Añadidos los valores a los que deben dejarse los campos state y resolution de un ticket.
1.2 Update references from OSOR to the https://devel.gvsig.org/redmine site

What is the gvSIG CLA?

Version: 1.0

Tip

This document is based on the OpenBravo legal aspects document.

The current gvSIG official projects copyright holder is the gvSIG Association. Any contribution to the gvSIG project requires to sign our contributor's agreement and send it by regular mail or by fax to gvSIG (this is an unfortunate consequence of copyright law in some jurisdictions). This requirement does not apply to external modules, localizations, documentation, except if they are contributed to us. It only applies to contributions that will be part of the core products.

The objective of contributor agreement is to protect the integrity of the project, its users and developers. The contributor agreement transfers the contributor's copyright to gvSIG who grants a non-exclusive license back to allow the contributor to use his/her own work. The rationale behind the agreement is:

  1. In case of a legal claim, having a single copyright owner makes it easier to defend the interests of the gvSIG users and developers. The gvSIG Association is committed to defend gvSIG projects in the event of any claim or infringement by third parties.
  2. The gvSIG Association can relicense its works under any other license in the future. When starting an open source project, the choice of license is intended to be permanent, but the experience of the past few years is that the ability to relicense a project is a useful tool in meeting challenges for open source projects. Not having that flexibility may be a drawback. Without the agreement, every single contributor must be contacted and unanimity reached in order to relicense a code base, or parts of the code must be reimplemented. This is true for all but the most permissively-licensed open source projects.
  3. The contributors assert that their contributions are original and not protected by any patents. It guarantees to all contributors in the project that all the contributions are original.

Contributor's agreements are standard procedure in open source projects followed by projects ranging from the Free Software Foundation to the OpenOffice.org project, including the Apache project, on which this agreement is loosely based.

If you are not contributing code within the framework of a company or an institution, (i.e. your work is done as an individual), you have just to sign the contribution agreement and send it to the gvSIG Association.

If you are a company, please ensure that someone authorised to sign on behalf of the company signs the agreement and lists the names of people that agreements covers. This is usually done by a senior manager in the organization. This helps to reduce the number of individuals agreements to be signed.

If you have any question regarding this contract please contact us gvsig-legal@gvsig.com.

References

Similar pages of other free software projects:

Change log
Version Description
1.0 First published version of the document

CLA status

Organizations

Organization name Date received
LSI (UJI) 2011/06/01
ai2 (UPV) 2011/06/01
DISID 2012/03/28
Laboratorio de Bases de Datos. Universidade da Coruña 2012/04/24
Software Colaborativo TBD
Prodevelop TBD
CartoLab TBD
iCarto TBD

Individual contributors

Name Date received
Fernando Pinotti (UPV) 2011/09/04
Fernando González 2012/03/26
Antonio Falciano 2012/08/02
César Martínez Izquierdo 2012/09/28

gvSIG code contribution profiles

gvSIG code contribution profiles

Version: 1.0

Table of contents

Introduction

This document integrates the description of the different contributor profiles that can participate on the development of gvSIG, presenting at the end on a pretty schematic way the main workflows available when contributing software code to gvSIG.

Described profiles are:

Profiles

External developer

Any community member interested on contributing patches. He doesn't have to had a strong commitment with the project and he should be able to do small contributions without too much barriers.

Project developer

A developer with write permission on the whole gvSIG source repository or at some section. He is a developer strongly committed to the project, providing code regularly, so he needs to be comfortable committing changes.

To obtain this role a request to the TSC Board will be presented and will pass with simple majority if (s)he fulfil the established metrics. If the metrics are not fulfilled, the motion will pass with a qualified majority of 3/4. This role can be lost if a request to the TSC Board is presented and will pass with the same criteria that to get the profile.

Maintainer

It's the person in charge to any task to coordinate the development of a subsystem. They will deal with tickets from external developers, or reassign them to project developers. On the other hand, from a technical point of view they will take care to maintain a high cohesion and loose coupling in the subsystem they maintain.

To obtain this role a request to the TSC Board will be presented and will pass with simple majority if (s)he fulfil the established metrics. If the metrics are not fulfilled, the motion will pass with a qualified majority of 3/4. This role can be lost if a request to the TSC Board is presented and will pass with the same criteria that to get the profile.

Reviewer

Is the person in charge of the review and evaluation of the changes on the subsystems started by someone's request or because a periodic supervision.

He's objective is to maintain stability and robustness of the application as a whole, focusing specially on subsystem interfaces and the collaborations between them.

She is a developer with an special sensitivity that encourages her to look with criticism the code, looking more for the impact of changes on the system than on the usefulness of the functionality that code adds.

This profile doesn't requires specific knowledge on the module affected by any change, nor a deep knowledge on gvSIG architecture, and they won't be assigned to any specific subsystem inside gvSIG.

An important note in that a reviewer is not to support any module or subsystem maintainer at all. If you understood that, please read carefully the maintainer description.

To get or loose this profiles the same rules that for maintainers will be applied.

Tester

Note

This tester description is not complete, here there are relevant information about their relation with the other roles described on this document.

A tester is a person in charge of verifying that the application behaves on the way it is noted on a ticket. If the ticket is about a bug fix, it will contain the code, but also all the relative information about how to reproduce the error and how to verify it has been fixed. If the ticket is about a new functionality, it will contain a description of its requirements and how the tester can assure they are fulfilled.

To qualify for this profile an appointment by the testing manager is the only requirement.

Software architecture support

Is a member of the gvSIG software architecture team who can be asked by any developer for advice or help in assessing the impact of a given change.

gvSIG code point of view of every role

Every role related with the development and interaction with the source code of gvSIG has a different point of view of the project. It can be of high level or in-depth. For example, a high level perspective will see a gvSIG product as a set of subsystems that interact trough a group of well defined interfaces. A low level point of view is focused on a subsystem implementation. With this definition in mind, next table shows the roles points of view on the gvSIG code:

Role Visibility
Software architecture support They have a general point of view of the application, looking at it as a whole.
Maintainer He looks for his module code, as well as any API his module interacts
Reviewer He looks at interfaces or even methods. He evaluates the impact of changes on the semantics, interfaces, method signatures or their context.

Rights and Obligations

The following are the duties and rights of each of the profiles:

Role Rights and Obligations
External developer
  • To open new tickets attaching code patches.
  • To know about Contributions and patches to the gvSIG code recommendations
  • To know about coding conventions used by the project
  • When your contribution modifies any API, the corresponding javadocs will be updated accordingly
  • If your contribution breaks any existing automated test, they will be updated accordingly
  • If the package maintainer requests it, you will provide additional or updated tests in order to cover the new behaviour contributed
  • If your contribution changes the Graphical User Interface, the maintainer could ask for an update on the user documentation to accept the patch
Project developer
  • Create new tickets attaching patches or references to changes at source code repository
  • Commit code to the source code repository (always with a ticket assigned to the commit)
  • To know about Contributions and patches to the gvSIG code recommendations.
  • To know about coding conventions used by the project.
  • To know when is allowed to commit changes to the source code repository and when is not. The project managers will notify about this timing on mailing lists.
  • To know well the development documentation.
  • Any uploaded code will have updated also the javadocs.
  • If your contribution breaks any existing automated test, they will be updated accordingly. Likewise, you will provide additional or updated tests in order to cover the new behaviour contributed.
  • Provide to the testers all the information they could need to validate the change, as well as update the test cases (nowadays this last requirement is not possible by technical impediments, but it will be needed as soon as they are solved).
  • If the package maintainer requests it, you will provide additional or updated tests in order to cover the new behaviour contributed
  • If your contribution changes the Graphical User Interface, the maintainer could ask for an update on the user documentation to accept the patch.
Maintainer
  • Create new tickets attaching patches or references to changes at source code repository
  • Commit code to the source code repository
  • Assign tickets to reviewers
  • Ask to software architecture team about the impact of a code change
  • Assign tickets to developers to commit changes to the source code repository or to ask for more information to the community contributor. That doesn't avoids revision, it's just to speed up the process if it has to be done.
  • Auto-assign a tickets with an attached patch and commit it or ask for any change to the contributor. This doesn't remove revision, it just speeds up the process if it has to be done.
  • To assure that tickets have all the information needed by testers to validate the change, and if this is not true, to claim for it to the developer that contributed the change.
  • As a maintainer is also a project developer, (s)he will have the same rights and obligations besides their specific ones.
  • To assure that tickets received on his subsystem are treated accordingly (assign tickets to reviewers or to developers)
  • To reject tickets without updated javadocs if they are needed (always asking first to the developer if the first time they weren't provided)
  • To reject tickets that broke any automated test existing at the project of the contributed code (always asking first to the developer if the first time they weren't provided)
  • To reject tickets with code that doesn't follow the project code conventions (always asking first to the developer if the first time they weren't followed)
  • To reject tickets that don't specify how a tester can verify the change solves the incorrect behaviour (always asking first to the developer if the first time it wasn't provided)
  • Maintain the configuration, information and documentation about the building process of the subsystem. If maven is used, assure that besides compilation, deploy mechanisms are working, site generation, etc. as well as the information stored at pom.xml file: developers, description, etc.
  • Be responsible on the application on corrections and new functionalities between different live versions of gvSIG, at least against superior versions. It's not necessary to apply or ask for changes on all versions, but at least (s)he has to create the tickets in order to not lose the changes. For example, there is a bug with a patch for gvSIG Desktop 1.x, it should be applied or at least to create the corresponding ticket for 2.x.
  • He is in charge to maintain a high cohesion and loose coupling in the subsystem he maintains
  • He is in charge of the source code version control he maintains
  • He has to coordinate changes to be ready for next releases of the application
  • He has to be aware of the dependencies of the subsystem he maintains
  • He has to maintain the user documentation updated, asking to the ticket creator for additional information or needed screenshots
  • He has to know about the project procedures associated with the user documentation generation
  • He has to know about the procedures associated with the process of releasing a new version of the project, binaries naming, where they have to be placed, how to update libraries,....
Reviewer
  • Create new tickets attaching patches or references to changes at source code repository
  • Commit code to the source code repository
  • Accept or reject tickets with code contributions
  • Ask to software architecture team about the impact of a code change when knowledge of gvSIG as a complete systems are needed.
  • Ask the maintainer when the code contribution is related with a subsystem with an assigned maintainer.
  • Review assigned tickets
  • Report on the ticket any detected problem on the code
  • Reject any ticket that broke existing automated tests on the project where the changes will be applied.
  • Reject any ticket without the proper documentation (javadocs) on the code changed or contributed.
  • Reject any ticket with code that doesn't follow the gvSIG code guidelines
  • Reject any ticket with code but without instructions for the testing team about how to verify that code works as expected
  • Fix small problems that the code contribution can arise, annotating that on the same ticket
  • If the ticket is a patch an the change is accepted, commit it to the source code repository
  • Inform the maintainer when (s)he can not attend an allocated ticket for review
Tester
  • To mark a ticket as a non resolved
  • To mark a ticket as a non valid
  • To mark a ticket a validated
  • Review assigned tickets by the testing manager and mark them as validated, non solved or waiting for more information
Software architecture support
  • Assign tickets to be reviewed.
  • Assign tickets to the reviewers to be reviewed on a given version stabilisation period, on those modules where there is no assigned maintainer.
  • Attend developers help requests

Activities restrictions

Next table shows what is not allowed to every role.

Role Restricitons
External developer
  • To commit code directly to the source repository
  • To approve a ticket with a patch
  • To auto-assign a ticket
  • To validate a ticket
Project developer
  • To approve a ticket with a patch or code contribution
  • To assign tickets
  • To validate tickets
Maintainer
  • Review his own patches or code contributions
Reviewer
  • When accepting code, to take decisions about functionality
  • Review their own tickets
  • Commit code from a ticket that has not be assigned to him by a maintainer or the architecture team

Role metrics

Next table shows the different metrics to take in account to obtain a role.

Role To obtain a role
Project developer
  • Provide at least three code patches
  • Participate on at least two gvSIG product revisions
  • To exists at least two reviewers, maintainers or software architecture team members supporting the candidate, specially those reviewers that had worked on candidate contributions.
Maintainer
  • Participate as a project developer on at least the complete period between two gvSIG revisions.
  • Participate actively on the wanted module, at least with 6 (six) code patches.
  • To exists at least one reviewer, maintainer or software architecture team member supporting the candidate, specially those reviewers that had worked on candidate contributions.
Reviewer
  • Participate as a project developer on at least the complete period between two gvSIG revisions.
  • To exist at least one reviewer, maintainer or software architecture team member supporting the candidate, specially those reviewers that had worked on candidate contributions.

This table shows some considerations to be taken in account when losing a role:

Role To lose a role
Project developer
  • Provide at least four consecutive code patches rejected after their revision by a maintainer or reviewer
  • Inadvertently repeated contributions that cause other errors in the application
  • Two years of no participation
  • If there is a clear dissociation with the project
Maintainer
  • Provide at least four consecutive code patches rejected after their revision by a reviewer or a software architecture team member
  • Two years of no participation
  • If there is a clear dissociation with the project
  • Four or more contributions to a module of an specific version, without applying or creating a new ticket for the superior version
Reviewer
  • Provide at least four consecutive code revisions where the software architecture team considers that the API syntax or semantics has been altered, affecting the behaviour of any other part of the application
  • Two years of no participation
  • If there is a clear dissociation with the project
  • If there is a neglect of their duties clearly and repeatedly

Use cases and work flows overview

Warning

In development

Use case 1: new ticket with patch
  • A new ticket is created with the bug or new functionality despription
  • The developer adds a source code patch
  • If the ticket is managed by a reviewer:
    • The maintainer or architecture team member assigns the ticket to a reviewer
    • If the reviewer detects something wrong, he adds a note on the ticket and if he sees that the contributor would solve it, he asks for fixing at the same ticket
    • When the reviewer agrees with the patch, he commits it to the SVN and updates the ticket, changing the status to reviewed
  • If the ticket is managed by a maintainer
    • The maintainer or architecture team member assigns the ticket to a maintainer
    • The maintainer commits the changes to the SVN and updates the ticket
    • The maintainer or an architecture team member assigns the ticket to a reviewer
    • If the reviewer detects something that can be wrong, informs of this on the ticket and ask the maintainer about fixing it
    • When the reviewer is happy with the changes updates the ticket to reviewed
  • If the ticket is managed by a project developer
    • The maintainer or architecture team member assigns the ticket to the project developer
    • The developer commits the changes to the SVN and updates the ticket
    • The maintainer or architecture team member assigns the ticket to a reviewer
    • If the reviewer detect something that can be wrong, informs of this on the ticket and ask the developer about fixing it
    • When the reviewer is happy with the changes updates the ticket to reviewed
Use case 2: ticket management by a project developer
  • The developer will firstly contact the project maintainer using the ticket comments to inform about his interest on solving that bug
  • The maintainer assigns the ticket to the developer
  • The developer commits the changes to the SVN and updates the ticket
  • The maintainer or architecture team member assigns the ticket to a reviewer
  • The reviewer checks the code and if everything is ok changes to ticket to reviewed
Use case 3: ticket management by a maintainer
  • The maintainer assigns to himself the ticket
  • The maintainer commits the changes and updates the ticket
  • The maintainer or an architecture team member assigns the ticket to a reviewer
  • The reviewer checks the code and if everything is ok changes the ticket to reviewed
Change registry
version Description
1.1 Added information about the workflow (to be reviewed)

Modules gvSIG-desktop

gvSIG-desktop v1

Proyect Maintainer Email
Applications    
  • appCatalogAndGazetteerClient
J.Piera jpiera@prodevelop.es
  • appgvSIG
Fran Peñarrubia fpenarru@gmail.com
Extensions    
  • extAddEventTheme
   
  • extAnnotations
   
  • extArcims
   
  • extCAD
Fran Puga fpuga@cartolab.es
  • extCatalogAndGazeteer
J.Piera jpiera@prodevelop.es
  • extCenterViewToPoint
Nacho Varela nachouve@gmail.com
  • extDataLocator
Fran Peñarrubia fpenarru@gmail.com
  • extDerivedGeometries
   
  • extDwg
   
  • extExpressionField
Fran Puga fpuga@cartolab.es
  • extGeoProcessing
   
  • extGeoProcessingExtensions
   
  • extGeoreferencing
   
  • extGPE-gvSIG
   
  • extHelp
   
  • extHyperlink
Pablo Sanxiao psanxiao@icarto.es
  • extI18n
   
  • extIconThemeBase
   
  • extJCRS
   
  • extJDBC
Fran Peñarrubia fpenarru@gmail.com
  • extLayerLoadingOrder
Fran Puga fpuga@cartolab.es
  • extOracleSpatial
   
  • extProjectBackup
   
  • extQuickInfo
   
  • extQuickPrint
   
  • extRasterTools-SE
   
  • extScripting
   
  • extSDE
   
  • extSelectionsTools
   
  • extSextanteGvsigBindings
   
  • extSymbology
Fran Peñarrubia fpenarru@gmail.com
  • extTableExport
   
  • extTableImport
   
  • extTableSummarize
   
  • extWCS
   
  • extWFS2
J.Piera jpiera@prodevelop.es
  • extWMS
Fran Peñarrubia fpenarru@gmail.com
Frameworks    
  • _fwAndami
   
Libraries    
  • libArcIMS
   
  • libCorePlugin
   
  • libDriverManager
   
  • libDwg
   
  • libDXF
   
  • libExceptions
   
  • libFMap
Fran Peñarrubia fpenarru@gmail.com
  • libGDBMS
Fran Peñarrubia fpenarru@gmail.com
  • libGeoUtils
   
  • libGPE
   
  • libGPE-GML
   
  • libGPE-KML
   
  • libGPE-XML
   
  • libInternationalization
   
  • libIverUtiles
   
  • libjCRS
   
  • libProjection
   
  • libRaster
   
  • libRemoteServices
   
  • libTopology
   
  • libUIComponent
   
  • org.gvsig.installer.app.extension
Nadal francisco_nad@gva.es
Another gvSIG 1.X proyects    
  • install
Fran Puga fpuga@cartolab.es
  • binaries
   
  • ChartLegend
   
  • NavTable
Andrés Maneiro amaneiro@icarto.es
  • ConsecutiveNumberExtension
   
  • CopyPasteGeom
   
  • NewGeoprocess
   
  • SelectDuplicatesExtension
   
Proyects not incluided in gvSIG 1.X    
  • extGraph
Fran Peñarrubia fpenarru@gmail.com
  • 3D
Jordi Torres jtorres@ai2.upv.es
  • Animation
Jordi Torres jtorres@ai2.upv.es

gvSIG-desktop v2

Proyect Maintainer Email Comments
  • appCatalog
  • extCatalog
     
  • appGazetteer
  • extGazetteer
     
  • appgvSIG
     
  • build
  • org.gvsig.core.maven.dependencies
     
  • extCenterViewToPoint
     
  • extDalTransformEventTheme
     
  • extDalTransformJoin
     
  • extDataLocator
     
  • extDwg
  • libDwg
     
  • extEditing
     
  • extExpressionField
     
  • extGeoDB
     
  • extGPE-gvSIG
     
  • extHelp
     
  • extI18n
     
  • extIconThemeBase
     
  • extJCRS
  • libjni-proj4
     
  • extWFS2
     
  • _fwAndami
     
  • _fwAndami-updater
     
  • libCompat
     
  • libCorePlugin
     
  • libDXF
     
  • libEvaluator_SQLJEP
     
  • libFMap_controls
     
  • libFMap_dal
     
  • libFMap_daldb
     
  • libFMap_dalfile
     
  • libFMap_dalindex
     
  • libFMap_geometries
     
  • libFMap_mapcontext
     
  • libInternationalization
     
  • libIverUtiles
     
  • libProjection
     
  • libRemoteServices
     
  • libUIComponent
     
  • org.gvsig.about
     
  • org.gvsig.annotation
  • org.gvsig.annotation.app
     
  • org.gvsig.app.document.layout.app
     
  • org.gvsig.app.document.table.app
     
  • org.gvsig.arcims
  • org.gvsig.arcims.feature.extension
  • org.gvsig.arcims.image.extension
     
  • org.gvsig.daltransform.app.mainplugin
     
  • org.gvsig.educa.batovi
  • org.gvsig.educa.thematicmap
  • org.gvsig.educa.thematicmap.app
José Manuel Vivó jmvivo@disid.com  
  • org.gvsig.exportto
  • org.gvsig.exportto.app
     
  • org.gvsig.external.jedit
     
  • org.gvsig.external.jump
     
  • org.gvsig.external.raven
     
  • org.gvsig.geocoding
  • org.gvsig.geocoding.extension
     
  • org.gvsig.geometrymeasurement.app
     
  • org.gvsig.geoprocess
     
  • org.gvsig.hyperlink.app
     
  • org.gvsig.installer
  • org.gvsig.installer.app
     
  • org.gvsig.metadata
  • org.gvsig.metadata.app
     
  • org.gvsig.mkmvnproject
     
  • org.gvsig.newlayer
  • org.gvsig.newlayer.app
     
  • org.gvsig.normalization.extension
     
  • org.gvsig.oracle
     
  • org.gvsig.personaldb
     
  • org.gvsig.raster
  • org.gvsig.raster.tools
  • org.gvsig.raster.cache
  • org.gvsig.raster.tilecache
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.ermapper
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.gdal
  • org.gvsig.jgdal
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.lizardtech
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.mosaic
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.netcdf
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.postgis
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.wcs
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.wms
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.raster.wmts
Nacho Brodín ibrodin@prodevelop.es  
  • org.gvsig.scripting
  • org.gvsig.scripting.app
     
  • org.gvsig.selectiontools.app
     
  • org.gvsig.symbology
  • org.gvsig.symbology.app
     
  • org.gvsig.testplan.app