The differences between versions 1.X and 2.X are very important in some areas of the application. There are important changes relating to:

- Construction of the project having moved from *ant* to *maven*.

- Standardisation of java package names.

- Data access architecture. The entire `data access`_ section has been rewritten in gvSIG.

- Re-engineering of the geometry access libraries.

- Rewriting of the mechanisms used for writing and retrieving data from the files of a gvSIG project.

- Rewriting of the mechanisms used for persisting the user data associated with a *plugin*.

- Change of the logging mechanism being used, from *log4j* to *slf4j*.

- The mechanism for packaging and installing *plugins* for gvSIG.

- The introduction of mechanisms for maintaining a separation between the API and implementation in the gvSIG code.

- Separation of the logic from the user interface. This is mainly in the parts of the application that have to be rewritten. In the parts where rewriting isn't necessary it can remain as it was.

- A guide to the `coding conventions`_ to be followed in gvSIG code has been developed.

In the light of these changes, there is no simple answer to the question *What needs to be taken into account when initiating a development in the 1.X line and then later migrating to the 2 line?*

The first issue that arises is that *compatibility can't be maintained*. Upon further reflection, there are some recommendations that can be followed, some more difficult than others. Some of them are listed here and developers will have to decide on their applicability to their projects:

- **Never modify gvSIG source code**. Although this may seem obvious, don't modify the gvSIG code, use it as is. There are extension points in gvSIG that allow you to *click* on many of the gvSIG features in order to customize them. For those features where this is not available tell us so that we can study them and provide a solution.

- **Work with a gvSIG installable, not with the source**. This is more than just a recommendation. Don't embed the gvSIG source along with your development in its *workspace*. Rather create a separate *workspace* for your development when deploying your *plugins* in a gvSIG installation.

- **Use maven as a construction mechanism**. There is a *maven* repository for gvSIG version 1.9. If you are able to prepare your project with *maven* then you should follow the multi-module structure recommended for the gvSIG 2 line.

  This is not essential and can be quite difficult if you aren't familiar with maven, but if you intend migrating to the gvSIG 2 line it is worth working towards.

- **Keep the API implementation and the contributed features separate**. Try to find a balance between a monolithic implementation and having several API and implementation libraries. Also try to ensure that dependencies between them are only through the API.

  If you want to start making the separation between the API and implementation in the 1.X code, you can use the mechanisms implemented in the *org.gvsig.tools* library for the gvSIG 2 line as these also work in the 1.X line.

- **Keep the data access sections within the application's logic during implementation**, and try as far as possible to keep track of those parts of the code that access data. When migrating to version 2.X these are the parts of the application that will have to be modified.

- **Keep the access to controlled geometries in the logic part of the development**. Changes in the handling of geometries are important in the 2.X line.

- **Control and document which parts of the application are saved with the project**. Data storage in the project has changed completely and you are now required to declare what will be stored in the project. It is therefore advisable to keep the data storage well-documented in order to faciliate the migration to 2.X projects.

- **Use the slf4j API as a logging mechanism on the log4j backend**. You can find more information on this in the document on Logging_.

- **Use the clonable interface**. Use this interface when you have to clone objects and follow the java recommendations for doing so. *Never use the project's persistence mechanisms for cloning an object*. You can find more information on this in the document on `cloning objects`_.

In general it is a good idea to read the sections on `Creating a gvSIG project`_ and `Migrating projects to gvSIG 2.0`_ in the gvSIG 2.0 developers guide.

.. _`Creating a gvSIG project` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/crear-un-proyecto-para-gvsig
.. _`Migrating projects to gvSIG 2.0` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0
.. _`cloning objects` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0/cloning-objects
.. _`Logging` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0/logging-1
.. _`data access` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0/fmap/data-access-1
.. _`coding conventions` : /web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/coding-development-guidelines/coding-conventions