When developing a project for gvSIG 2.0 we must consider several things if we want it to have the official endorsement of gvSIG and become part of the official gvSIG release.

• Maven must be used as the tool to build the project.

  Maven defines the group name, the groupId, and the identifier, the artifactId for the project. The groupID will be org.gvsig and the artifactId consists of the groupID followed by an identifier of the project.

  For example, when creating a topography plugin for gvSIG, all the project packages will start with org.gvsig.topography.

  The artifactId is used:

  • To identify the root package of our Java project. All our packages begin with the artifactId.
  • As name for our Eclipse project. Eclipse projects for gvSIG development have the same name as the artifactId.
  • When naming the jars: the names of jars that are generated for our project begin with the artifactId followed by the version of the project and the Maven classifier.

• There should be a strict separation between API and implementation.

  This seems obvious, but very often there is no such separation, and when there is a separation it is usually not as strict as is required by gvSIG.

  The main reason for this are issues such as:

  • How do we assess the scope of a change in the code? What would be the impact on the gvSIG application if we modify this?

    Having the APIs strictly defined greatly facilitates the response to this question.

  • How can we properly document the use of libraries? When the API and the implementation are separated, it is easier to focus on the API documentation than when it is mixed with the implementation.

  • How can we run automated tests on our library? If we have a clear and well-defined API, we can focus on preparing automated tests to check the specifications of the API so that we can easily verify whether a change in implementation will affect the usage of the API.

• There must be an automated test system to verify the functioning of the API in our project. Until now JUnit is being used to perform these tasks.

• The APIs must be documented and this documentation must be uploaded to a public website.

  For documentation of interfaces and classes of the APIs, Javadocs will be used. The API documentation should be complete and in English. To generate and deploy the documentation, the Maven tool for generating sites will be used.

• The dependencies of our project on other libraries must be indicated.

  This is done by keeping the ManageDependencies in the root of the Maven project updated.

• The project must come with a test plan. This test plan should work by way of a series of acceptance tests that the project should go through after every gvSIG build until the final version.

• User documentation of the project must be prepared in ReST (reStructured Text) format, preferably in English.

• The jars of the project must be deployed in a Maven repository, and a versioning policy must be followed corresponding with the changes made to the project. gvSIG has its own Maven repository in which to deploy its libraries, but you can use another if appropriate.

• A developers guide, preferably in English, to introduce developers in the use of the libraries of the project would be appreciated.

• When generating installable packages of your plugin for gvSIG, make sure that it has a unique build number. There must be a way to uniquely identify a distribution or packaging of your plugin that does not leave any doubt to which version it applies. Therefore, a unique build number must be assigned to each packaging for gvSIG.