Gvsig Sviluppatore 1 11

1.11.
http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-dev...
Trabajar con el ncleo de gvSIG Crear un instalable de gvSIG Normas de codificacion y desarrollo Coding conventions Publicacin de una versin oficial de una extensin Otra documentacion de interes Anexos Migracion al repositorio de subversion de OSOR Desarrollar con gvSIG 1.11 pensando en gvSIG 2.0
Trabajar con el ncleo de gvSIG

Crear un instalable de gvSIG Preparacin:
Copiar a algn directorio, y meterlo en path, los scripts de python que se han dejado en el proyecto install del workspace (concretamente install/scripts/svnScripts). Estos scripts realizan en batch algunas tareas con el svn y nuestro workspace que veremos a continuacin. En el archivo svn-utils.py debemos sustituir en la linea 32 las cadenas "USUARIO" y "PASSWORD" por los valores correspondientes a nuestro usuario en el repositorio.
Pasos a seguir:
Nota: Los ejemplos se han puesto considerando que la versin de gvSIG cuyo instalador se va a generar es la 1.11.0. Si se va a generar un instalador de una versin posterior, sustityase donde aparezca 1.11.0 o 1_11_0 por la versin correspondiente. Si ha cambiado la versin de gvSIG, ahora solamente hay que cambiarla en el archivo package.info del proyecto appgvSIG en las propiedades version y gvSIG-version. 1.- Comunicar a la lista de desarrollo el nmero de versin y esperar un poco para que suban sus cambios (mirar en el archivo build.number de la extensin actual e incrementarlo en uno ) ejemplo:
Hola, Se va a generar inmediatamente un nuevo build de gvSIG 1.11 para testing. Este build se extraer del Trunk. Si tenis algo pendiente, subidlo ya. Saludos.
2.- Quitar el build automatically. 3.- Sincronizacin con el svn:

svn update *
4.- Hacer clean-all y build all del build.xml de appgvSIG para el workspace (a travs de external tools). 5.- Refresh para todo el workspace. 6.- Comprobar que gvSIG arranca y carga lo que esperamos 7.- Ejecutar en consola de shell en el directorio del workspace:
1 di 14
22/02/2012 10.33
1.11.0
svn update *
para descargar los cambios. 7.1.- Si no hay cambios (esto se mira en la ventana del shell), se pasa al siguiente punto. 7.2.- Si s los hay, se hace sincronize y se bajan los cambios, y se repite todo desde el punto 4 (clean all y build all) hasta que en este punto no haya cambios. 8.- Ejecutar en consola de shell en el directorio del workspace:
svn-preparar_tag trunk pre_v1_11_0_Build_xxxx
donde xxxx es el el nuevo build number (indicado en el punto 1). Esto hace que se copien los proyectos desde el trunk al tag/tmp_build/ (se realiza remotamente en el servidor sin hacer una copia en local). 9.- Cerrar eclipse 10.- Ejecutar en consola de shell en el directorio del workspace:
svn-sw_ToTmp_workspace
Esto hace un switch para cada uno de los proyectos a la nueva ubicacin (tag/tmp_build). 11.- Hacer clean-all y build all del build.xml de appgvSIG para el workspace (a travs de external tools). Comprobar que gvSIG arranca y carga lo que esperamos. 12.- Si hay que cambiar etiquetas de distribucin (alpha, beta, RC1, ...) o nmero de versin cambiarlas en el:
install/instalador-gvSIG-lin/installer_files/LEEME (Aqu solo en caso de cambio de nmero de versin) install/instalador-gvSIG-lin/installer_files/README (Aqu solo en caso de cambio de nmero de versin) install/instalador-gvSIG-win/installer_files/LEEME.txt (Aqu solo en caso de cambio de nmero de versin) install/instalador-gvSIG-win/installer_files/README.txt (Aqu solo en caso de cambio de nmero de versin) install/build.properties (Aqu solo en caso de cambio de nmero de versin) install/instalador-gvSIG-lin/install_template.xml (appname y appversion. Hay que asegurarse de no dejar espacios y sustituirlos por guiones bajos) install/instalador-gvSIG-win/install_15_template.xml (appname y appversion. Hay que asegurarse de no dejar espacios y sustituirlos por guiones bajos) _fwAndami/theme/andami-theme.xml (en dos sitios) appgvSIG/package.info.
13.- Ahora desde external tools configurations ejecutamos el target make-binary-distribution del build.xml del proyecto appgvSIG . Esto hace que se incremente el build number de gvSIG. 14.- Comprobar que gvSIG arranca y carga lo que esperamos. Comprobar en el about de la aplicacin que el build number es el que toca. 15.- Finalmente ejecutamos los siguientes targets del build.xml del proyecto install: check, linux* y windows* NOTA: Durante la ejecucin de estos dos targets, el proceso se parar y mostrar un cuadro de dialogo con el texto "Instale en este momento las contribuciones externas y despus contine con este proceso. Cuando el instalador pregunte el lugar donde est instalado gvSIG, proporcinele la ruta al directorio prev_install que se ha creado nuevo en el directorio INSTALL de su workspace. Desea continuar ahora?". Si queremos incoporar dichas contribuciones debemos hacerlo ahora: Si tenemos paquetes de instalacin para Linux los ejecutamos
2 di 14
22/02/2012 10.33
1.11.0
(tanto si estamos ejecutando el target "linux" como el "windows") y le suministramos (como dice el texto) la ruta al directorio prev_install del proyecto install del workspace. Si no, copiamos la extensin correspondiente al directorio prev_install/bin/gvSIG/extensiones que se ha creado nuevo en el directorio install de su workspace Debemos asegurarnos de que se han copiado correctamente los ficheros "package.info" dentro de cada una de las extensiones incorporadas, y que el contenido de ellos es el que corresponde. Para continuar con el proceso, seleccionamos "S" en el desplegable y pulsamos "OK". Puede ser recomendable la ejecucin de estos targets desde lnea de comandos:
- ant -f build.xml check Linux - ant -f build.xml check Windows
porque con las modificaciones que se han incorporado para la inclusin de las contribuciones externas, al ejecutarlos desde eclipse, se pierde la salida de la consola y no podremos ver si ha ocurrido algn error posterior a este punto. 16.- Se generan cuatro archivos, dos para windows y dos para linux (con y sin jre). 17.- Instalamos la aplicacin para probarla y verificamos que la versin es la correcta (en el men help/about tiene que figurar el nuevo build number). 18.- Si todo va bien subimos los archivos al servidor ftp de osor dentro de la carperta:
/home/groups/gvsig-desktop/www/downloads/pub/projects/gvSIG-desktop/devel/gvSIG-1_11/gvSIG-1_11_0/XXXX
donde XXXX es el nuevo build number (indicado en el punto 1) 19.- Si hemos cambiado etiquetas de distribucin (alpha, beta, etc.) (pto. 12) habr que subir estos cambios al tag en un solo commit. 20.- Cerrar eclipse. 21.- Ejecutar en consola de shell en el directorio del workspace:
svn-sw_workspace trunk
Esto hace un switch para cada uno de los proyectos a la ubicacin original (trunk). 22.- Ejecutar en consola de shell en el directorio del workspace:
svn-merge_workspace_with_tmp_build
Esto hace un merge para cada uno de los proyectos a la ubicacin original (trunk). 23.- Hacer commit en el trunk con los cambios que hemos hecho en el tag. El mensaje del commit ser v1_11_0_Build_xxxx donde xxxx ser el nmero de build 24.- Desde el svn explorer de eclipse u otra utilidad renombrar el tag tmp_build a v1_11_0_Build_xxxx. El mensaje del commit ser v1_11_0_Build_xxxx donde xxxx ser el nmero de build 25.- Crear un ticket de tipo nota en el bugtracking (tomar como plantilla anteriores tickets de este tipo, por ejemplo del build 1305 https://forge.osor.eu/tracker/index.php?func=detail&aid=15259&group_id=89&atid=804). No olvidar en el mismo comentario poner el enlace a las descargas de los binarios.
3 di 14
22/02/2012 10.33
1.11.0
Normas de codificacion y desarrollo

Coding conventions
Contents Forewords Why code conventions How to apply? gvSIG specific coding conventions Mandatory conventions Advised conventions
Forewords
This document describes a list of coding conventions that are required for code submissions to the project. By default, the coding conventions for most Open Source Projects should follow the existing coding conventions in the code that you are working on. For example, if the bracket is on the same line as the if statement, then you should write all your code to have that convention. If you commit code that does not follow these conventions and you are caught, you are responsible for also fixing your own code. Below is a list of coding conventions that are specific to gvSIG, everything else not specificially mentioned here should follow the official Sun Java Coding Conventions
Why code conventions

As explained in the Sun Java Coding Conventions: Code conventions are important to programmers for a number of reasons: 80% of the lifetime cost of a piece of software goes to maintenance. Hardly any software is maintained for its whole life by the original author. Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly. If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.
How to apply?
Having coding conventions is nice but having a way to ensure they are applied is even better ... :-) The gvSIG maven configuration has a checkstyle target which performs coding conventions using the Checkstyle tool. Please run this target before committing any code. Also the eclipse configuration needed to format the source code taking into account the code conventions defined in the current document will be available in the org.gvsig.maven.base.build project, from the gvsig-tools OSOR project. If the project you are working with has a prepare-workspace.xml file which you have used to configure your workspace, you will have those files already downloaded and available into the folder:
WORKSPACE/org.gvsig.maven.base.build/eclipse-configs
Otherwise, you may download all the files through the repository URL:
4 di 14
22/02/2012 10.33
1.11.0
https://svn.forge.osor.eu/svn/gvsig-tools/org.gvsig.maven.base/trunk/org.gvsig.maven.base/org.gvsig.maven.base. To import those configurations perform the following: 1. Clean up: Go to Window > Preferences > Java > Code Style > Clean Up and click the button Import. In the file system explorer, select the clean_up.xml file.
1. Code templates: Go to Window > Preferences > Java > Code Style > Code Templates and click the button Import. In the file system explorer, select the code_templates.xml file. Activate the option Automatically add comments for new methods and types.
5 di 14
22/02/2012 10.33
1.11.0
1. Formatter: Go to Window > Preferences > Java > Code Style > Formatter and click the button Import. In the file system explorer, select the formatter.xml file.
6 di 14
22/02/2012 10.33
1.11.0
1. Organize imports: Go to Window > Preferences > Java > Code Style > Organize Imports and click the button Import. In the file system explorer, select the organize_imports.importorder file.
7 di 14
22/02/2012 10.33
1.11.0
gvSIG specific coding conventions

Mandatory conventions 1. Headers All source files must begin with the following comment:
/* gvSIG. Geographic Information System of the Valencian Government * * Copyright (C) 2007-2008 Infrastructures and Transports Department * of the Valencian Government (CIT) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, * MA 02110-1301, USA. * */
2. Indentations 4 spaces. NO tabs. 3. Javadoc All API interfaces and classes must be fully documented through javadocs comments at
8 di 14
22/02/2012 10.33
1.11.0
interface/class, method and package level. When you inherit or extend from another interface or class which is already documented, and implement or rewrite one of the parent methods, don't write any javadoc comments, as they are also inherited since java 1.4. 4. Brackets All brackets should begin at the end of the line that begins the statement, and end on a new line indented to the beginning of the statement. Example: AVOID:
public class MyClass { public void someMethod() { if (...) { // Do something } } }
RIGHT:
public class MyClass { public void someMethod() { if (...) { // Do something } } }
Brackets are mandatory even for single line statements:

if (expression) // some code if (expression) { // some code } // AVOID!
// RIGHT
5. Blank Spaces Keywords followed by a parenthesis should be separated by a space. Example:

while (true) { // some code }
Blank space should appear after commas in argument lists. Binary operators should be separated from their operands by spaces:
a += c + d; a = (a + b) / (c * d); while (d++ = s++) { n++; } printSize("size is " + foo + "\n");
6. Class variables Class variables should not have any prefix or suffix related to its data type or scope. Example:
9 di 14
22/02/2012 10.33
1.11.0
String nameString; String name;
// AVOID! // RIGHT
7. Parameter names Method parameters should be prefixed by "the" for differentiating them from inner variables, when there is an inner variable with the same name or use. For example:
public void someMethod(String theClassName) { String className; // inner variable }
8. Line length Avoid lines longer than 80 characters for Code, comments, ... 9. Versioning All .java files should have a @version tag like the one below into the class javadoc comment:
@version $Id$
10. Logging Do not use System.out to log. Instead, use the SLF4J logging API. For example:
private static final Logger LOG = LoggerFactory.getLogger(MyClass.class); public void someMethod() { LOG.debug("some debug text"); }
For more information on SLF4J usage, you can read the Logging document. 11. Exception handling Managing exceptions correctly requires experience. This is not supposed to be a guide on managing exceptions, simply a few best practices. Rule 1: Try to catch exceptions as much as possible and rethrow higher level exceptions (meaning hiding the low level detailed and putting a message that is more related to the function of your code). Rule 2: It is important not to loose the stack trace which contains important information. Use chained exceptions for that. Rule 3: Always log the exception at the higher level (ie. where it is handled and not rethrown). Rule 4: Try to avoid catching Throwable or Exception and catch specific exceptions instead. Rule 5: Create one parent Exception for each API library, so methods of the API that throw any exception use that parent exception or one of the child ones. Rule 6: If you have an exception or an error which can't be handled or resolved by code, throw or rethrow a BaseRuntimeException subclass. An example:
10 di 14
22/02/2012 10.33
1.11.0
public void getTestClass() { try { Class responseClass = Class.forName("some.package.MyClass"); } catch (ClassNotFoundException cnfe) { String message = "Cannot instantiate test class"; LOG.error(message, ex); throw new ChainedRuntimeException(message, e); } }
12. Qualified imports All import statements should containing the full class name of classes to import and should not use the "*" notation: An example:
// AVOID! import java.util.*; import java.net.*; // RIGHT import java.util.Date; import java.net.HttpURLConnection;
13. Use interfaces in the declaration of methods and variables. By example, if you need a variable x that is a list, declare it as List instead an ArrayList:
// AVOID! ArrayList x = new ArrayList(); HashMap y = new HashMap(); public HashMap create(ArrayList keys, ArrarList values) { ... } // RIGHT List x = new ArrayList(); Map y = new HashMap(); public Map create(List keys, List values) { ... }
14. API packages Usually, API interfaces and classes will belong to the library's main root package. If you create subpackages, use them to group by functionality, not by type. 15. How to name packages All packages must begin with org.gvsig. For more information on this convention, you can read the How to name packages document. Advised conventions 1. How to name interfaces and classes Attention! TODO For more information on this convention, you can read the How to name interfaces and classes document.
11 di 14
22/02/2012 10.33
1.11.0
Publicacin de una versin oficial de una extensin
Otra documentacion de interes

La lnea 1.X de gvSIG presenta una compatibilidad de cdigo entre las distintas versines bastante elevada, con lo que gran parte de la documentacin existente para las versines 1.0/1.1 y 1.9 puede ser valida para esta versin. As pues puede ser til consultar la documentacin de: Gua de referencia para gvSIG 1.1 Gua de extensiones para gvSIG 1.9 En donde puede encontrar documentacin sobre parte de la arquitectura vlida para la lnea 1.X de gvSIG. As mismo tambin pueden serle tiles los documentos aportados por la comunidad de: Introduccin al desarrollo con gvSIG v1.1 Construir gvSIG 1.1 desde el repositorio SVN
Anexos
Migracion al repositorio de subversion de OSOR
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:
12 di 14
22/02/2012 10.33
1.11.0
# 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
Desarrollar con gvSIG 1.11 pensando en gvSIG 2.0

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.
13 di 14
22/02/2012 10.33
1.11.0
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.
----------------------------------1. Error 'You are not allowed to access 'getId' in this context' accediendo al documento Publicacin de una versin oficial de una extensin, [1.11.0, Publicaci\xf3n de una versi\xf3n oficial de una extensi\xf3n]
14 di 14
22/02/2012 10.33

Gvsig Sviluppatore 1 11

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gvsig Sviluppatore 1 11

Uploaded by

Copyright:

Available Formats

1.11.

Trabajar con el ncleo de gvSIG

2.- Quitar el build automatically. 3.- Sincronizacin con el svn:

Normas de codificacion y desarrollo

Why code conventions

gvSIG specific coding conventions

Brackets are mandatory even for single line statements:

5. Blank Spaces Keywords followed by a parenthesis should be separated by a space. Example:

String nameString; String name;

Publicacin de una versin oficial de una extensin

Otra documentacion de interes

Desarrollar con gvSIG 1.11 pensando en gvSIG 2.0

You might also like