The gvSIG subversion repository was moved from its own server at the gvsig.org domain to a server hosted in OSOR during the week of April 12th 2010.
The easiest way is to do a checkout of the project again in a new workspace. However, if we have changes to upload, another option is to change the reference to the subversion server in our own workspace.
At first, we have two options for this:
From eclipse: (for lack of testing) we can use the option Team > Disconnect on a project, and then Team > Share project indicating the new URL to use.
From console: we can use the option of the subversion client svn switch --relocate OLD_URL NEW_URL folder. For example, to migrate the build project of the 2.0 (from the same build project), we'd use:
svn switch --relocate \ https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/build \ https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/build \ .
All of this, project by project. If we have a unix shell (we are on linux, mac, windows with the cygnus utilities, etc.) we can use the following instructions (including to create a script) to migrate a complete workspace of the gvSIG core:
# Andami
svn switch --relocate \
https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/frameworks/_fwAndami \
https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/frameworks/_fwAndami \
_fwAndami
# Root projects
for project in build binaries org.gvsig.core.maven.dependencies;
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/${project} \
https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/${project} \
${project};
done
# Applications
for project in app*;
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/applications/${project} \
https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/applications/${project} \
${project};
done
# Libraries
for project in lib*;
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/libraries/${project} \
https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/libraries/${project} \
${project};
done
# Extensions
for project in ext* org.gvsig.symbology;
do svn switch --relocate https://gvsig.org/svn/gvSIG/branches/v2_0_0_prep/extensions/${project} \
https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/extensions/${project} \
${project};
done
The differences between versions 1.X and 2.X are very important in some areas of the application. There are important changes relating to:
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.
Cached time 11/22/13 08:43:28