Trabajar con el núcleo de gvSIG

Crear un instalable de gvSIG

Preparación:

Copiar a algún 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 continuación.

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 versión de gvSIG cuyo instalador se va a generar es la 1.11.0. Si se va a generar un instalador de una versión posterior, sustitúyase donde aparezca 1.11.0 o 1_11_0 por la versión correspondiente. Si ha cambiado la versión 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 número de versión y esperar un poco para que suban sus cambios (mirar en el archivo build.number de la extensión 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 tenéis algo pendiente, subidlo ya.

Saludos.

2.- Quitar el build automatically.

3.- Sincronización con el svn:

svn update *

4.- Hacer clean-all y build all del build.xml de appgvSIG para el workspace (a través 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:

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 ubicación (tag/tmp_build).

11.- Hacer clean-all y build all del build.xml de appgvSIG para el workspace (a través de external tools). Comprobar que gvSIG arranca y carga lo que esperamos.

12.- Si hay que cambiar etiquetas de distribución (alpha, beta, RC1, ...) o número de versión cambiarlas en el:

install/instalador-gvSIG-lin/installer_files/LEEME (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-lin/installer_files/README (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-win/installer_files/LEEME.txt (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-win/installer_files/README.txt (Aquí solo en caso de cambio de número de versión)
install/build.properties (Aquí solo en caso de cambio de número de versión)
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 aplicación 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 ejecución 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 después continúe con este proceso. Cuando el instalador pregunte el lugar donde está instalado gvSIG, proporciónele 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 instalación para Linux los ejecutamos (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 extensión 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 ejecución de estos targets desde línea de comandos:

- ant -f build.xml check Linux
- ant -f build.xml check Windows

porque con las modificaciones que se han incorporado para la inclusión de las contribuciones externas, al ejecutarlos desde eclipse, se pierde la salida de la consola y no podremos ver si ha ocurrido algún error posterior a este punto.

16.- Se generan cuatro archivos, dos para windows y dos para linux (con y sin jre).

17.- Instalamos la aplicación para probarla y verificamos que la versión 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 distribución (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 ubicación 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 ubicación 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 número 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 número 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.


Normas de codificacion y desarrollo

Coding conventions

Contents

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:

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:

https://devel.gvsig.org/svn/gvsig-tools/org.gvsig.maven.base/trunk/org.gvsig.maven.base/org.gvsig.maven.base.build/src/main/resources/org.gvsig.maven.base.build/eclipse-configs/

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.
images/clean_up_optim.png
  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.
images/code_templates_optim.png
  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.
images/formatter_optim.png
  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.
images/organize_imports_optim.png

gvSIG specific coding conventions

Mandatory conventions

  1. Headers

    Look at the Headers document for more information.

  2. Indentations

    4 spaces. NO tabs.

  3. Javadoc

    All API interfaces and classes must be fully documented through javadocs comments at 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)       // AVOID!
    // some code

if (expression) {     // RIGHT
    // some code
}

  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:

    String nameString;   // AVOID!

String name;         // 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:

    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.


Documento no accesible

Publicación de una versión oficial de una extensión


Otra documentacion de interes

La línea 1.X de gvSIG presenta una compatibilidad de código entre las distintas versiónes bastante elevada, con lo que gran parte de la documentación existente para las versiónes 1.0/1.1 y 1.9 puede ser valida para esta versión.

Así pues puede ser útil consultar la documentación de:

En donde puede encontrar documentación sobre parte de la arquitectura válida para la línea 1.X de gvSIG.

Así mismo también pueden serle útiles los documentos aportados por la comunidad de:


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:

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

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:

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:

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 Publicación de una versión oficial de una extensión, [1.11.0, Publicaci\xf3n de una versi\xf3n oficial de una extensi\xf3n]

Cached time 11/21/13 17:13:34 Clear cache and reload