Artículos etiquetados con:java
Cómo crear un arquetipo Maven desde un proyecto existente

Habitualmente, durante el ciclo de vida de los proyectos se desarrollan soluciones, herramientas y configuraciones que pueden ser objeto de reutilizarlos en próximas aventuras.

Para esto, cada equipo (o grupo de equipos gestionados) debe desarrollar un conjunto de elementos que se utilicen repetidamente con el fin de ofrecer productos más sólidos y de mayor calidad o abaratar los costes del desarrollo.

En otras palabras, se desarrolla una pila tecnológica en base a la experiencia y conocimientos adquiridos con la iteración de los proyectos. En Maven, para generar un nuevo proyecto que cumpla con las especificaciones o características propias de esa pila tecnológica utilizamos los arquetipos.

Conceptualmente un arquetipo es básicamente una plantilla. Es decir, un patrón o modelo original desde el que se generarán otros elementos del mismo tipo. En desarrollo nos apoyamos en los arquetipos para reutilizar código y arquitecturas.

El objetivo de este post es obtener un arquetipo Maven desde un proyecto existente y generar otro proyecto desde ese arquetipo para reutilizar código modificado.

Antes de empezar, este es el entorno utilizado para el tutorial:

  • Hardware: Intel® Core™ i7-7500U CPU @ 2.70GHz, 16GB de RAM
  • SO: Ubuntu 16.04 LTS
  • JDK8
  • Maven 3
  • Git 2.7.4

 

1. CLONAR UN PROYECTO EJEMPLO

Utilizaremos una guía de spring boot: https://github.com/spring-guides/gs-spring-boot

Clonamos el proyecto:

git clone https://github.com/spring-guides/gs-spring-boot.git

Lo probamos:

cd gs-spring-boot/initial/
mvn spring-boot:run

Abrimos un navegador web ¡y listo!

Arquetipo Maven - Ejecución Spring Boot - SDOS

 

2. MODIFICAR EL PROYECTO

Vamos a modificar el proyecto para que sea nuestro “modelo”. Para ello vamos a cambiar simplemente el mensaje de bienvenida que se encuentra en el archivo ~/gs-spring-boot/initial/src/main/java/hello/HelloController.java.

package hello;

import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestMapping;

@RestController
public class HelloController {
    
    @RequestMapping("/")
    public String index() {
        return "Hola arquetipo!!";
    }
    
}

¡Ahora sí!

Arquetipo Maven - Ejecución Modificación Proyecto - SDOS

 

 

3. GENERAR E INSTALAR EL ARQUETIPO

Para generar el arquetipo utilizaremos el Maven Archetype Plugin desde command line. El resultado será una plantilla con los mismos archivos del proyecto desde el cual hemos partido.

Lo primero que haremos es crear un archivo de propiedades para definir el Maven GAV (groupId, artifactId, version) para nuestro arquetipo customizado. Para ello crearemos el archivo ~/gs-spring-boot/initial/my_archetype.properties con el siguiente contenido:

archetype.groupId=es.sdos
archetype.artifactId=sdos-custom-archetype
archetype.package=es.sdos.ca
archetype.version=0.0.1
## groupId por defecto para proyectos generados a partir de este arquetipo
groupId=es.sdos
## artifactId por defecto para proyectos generados a partir de este arquetipo
artifactId=sdos-example

Y ejecutamos la siguiente sentencia:

cd ~/gs-spring-boot/initial
mvn clean archetype:create-from-project -Darchetype.properties="my_archetype.properties"

En este momento ya tenemos el proyecto de tipo arquetipo generado con todos los recursos presentes en el proyecto clonado inicialmente y posteriormente modificado. Vamos a instalarlo en el repositorio local:

cd ~/gs-spring-boot/initial/target/generated-sources/archetype/
mvn install

Arquetipo Maven - Instalación - SDOS

 

 

4. CREAR UN NUEVO PROYECTO

Para crear el proyecto, introducimos las siguientes sentencias:

mkdir /tmp/proyecto-prueba-workspace
cd /tmp/proyecto-prueba-workspace/
mvn archetype:generate -Dfilter=es.sdos:sdos-custom-archetype

La consola entrará en modo interactivo, enumerará la lista de arquetipos encontrados en los repositorios configurados otorgándoles un número ordinal. Por ejemplo:

Arquetipo Maven - Proyecto desde Arquetipo - SDOS

 

En nuestro caso, seleccionamos el número 1 o que el que corresponda a es.sdos:sdos-custom-archetype.

Ahora, seguirá preguntando las propiedades para el nuevo proyecto. Estas deben ser nuestras repuestas:

  • groupId: es.sdos
  • artifactId: ejemplo
  • version: 0.0.1-SNAPSHOT
  • package: es.sdos (o simplemente pulsamos “enter”)

En este punto nos solicitará una confirmación. Le decimos que sí (“Y”).

Arquetipo Maven - Confirmación Proyecto - SDOS

 

 

5. PROBAR EL PROYECTO

Finalmente, para probar el proyecto, ejecutamos las sentencias:

cd /tmp/proyecto-prueba-workspace/ejemplo/
mvn spring-boot:run

Arquetipo Maven - Ejecución Proyecto - SDOS

 

Con esto habríamos concluido. Al abrir el navegador, se desplegará un nuevo proyecto con nuestras modificaciones.

 

CONCLUSIONES

Después de modificar el código de un proyecto existente, hemos utilizado de manera rápida y eficaz el plugin de Maven Archetype para heredar esas modificaciones a través de un arquetipo.

Realmente, invirtiendo poco tiempo, podemos aprovechar cualquier proyecto disponible para utilizarlo de punto de partida en el futuro.

Puedes encontrar todo el código fuente aquí.

 


Qué es y cómo elaborar un Code Style

Cuando somos pequeños y estamos empezando a escribir es importante seguir unas pautas para que todo el mundo entienda nuestra letra. Decir “¡pero si yo lo entiendo claramente!” no sirve de nada.

Siguiendo este símil, a la hora de escribir código es de suma importancia hacerlo de forma clara, concisa y, ante todo, legible. En este post veremos qué es un Code Style, qué debería contener y por qué es tan importante a la hora de escribir código con buena letra.

 

¿QUÉ ES EL CODE STYLE?

Podríamos decir que es el cuadernillo Rubio de los desarrolladores. Se trata de un documento que reúne una serie de guías o pautas a seguir tanto en la estructura del código como en la forma de implementarlo.

 

¿POR QUÉ ES TAN NECESARIO?

Por norma general, en todos los equipos hay bastantes programadores, cada uno de su madre y de su padre, con sus manías o costumbres. Debido a esto, llegar a un consenso puede ser una batalla campal en los inicios pero, nos guste o no, tenemos que llegar a un acuerdo.

Lo importante de un buen Code Style es que no venga impuesto por nadie y se llegue a una correcta definición entre todas las personas del equipo. Además, estará siempre sujeto a cambios y actualizaciones. Es muy importante que se escuchen todas las propuestas y se lleven a foro para evaluarlas y estudiar su posible cabida. De esta forma, todos nos sentimos parte de él y lo acataremos sin problemas.

 

¿QUIÉN DEBE SEGUIRLO?

Todo el mundo, sin excepciones. No hay excusas para aplicar el Code Style en todos los proyectos. Ni por las prisas, presiones, ni nada por el estilo; el código debe ser claro siempre. De esta forma si alguien nuevo llega a nuestro proyecto, sus tareas no se convertirán en una muerte a pellizcos y evitaremos que sea casi imposible cualquier modificación en el código.

 

¿QUÉ DEBERÍA CONTENER?

A grandes rasgos, en las secciones de nuestro Code Style incluiremos:

 

NOMECLATURA UTILIZADA

Establecemos pautas para la definición de nombre de:

  • Ids. Cuanta más información demos, mejor.
    Ej: login__input__username
  • Clases e interfaces. Comenzar por mayúsculas, usar camel case, tener un nombre descriptivo y especificar a qué hace referencia la clase.
    Ej: LoginFragment, LoginActivity, etc.
  • Variables. Tienen que ser autodescriptivas (nada de aux1, aux2, etc.). Proporcionaremos además información adicional sobre su accesibilidad.
    Ej: private String mTriesToForceCloseApp.
  • Métodos. Al igual que las variables, serán autodescriptivos y comenzarán siempre por un verbo.
    Ej: clickOnAcceptBtn()

 

DEFINICIÓN DE BLOQUES FUNCIONALES

Es importante la distinción de bloques funcionales simplemente con un primer vistazo a nuestro código, evitando que todo el código esté apelotonado, complicando así su lectura y comprensión.

  • Try/catch. Los bloques catch nunca estarán vacíos y respetaremos tanto los saltos de línea como los espaciados.

    try {
        ejecutaUnMetodo();
     
    } catch (MyException e) {
        Log.e("MyTag", "Esto es un pete capturado");
    }
    
  • Switch. Separaremos los distintos case con un salto de línea si llevan un break para separar bloques funcionales. Para los case que tienen código pero no tengan un break, incluiremos una anotación para indicar que la ejecución sigue en el siguiente case.

    switch(entrada) {
        case 1:
        case 2:
            ejecutaMetodoUno();
            /* falls through */
        case 3:
            ejecutaMetodoDos();
            break;
     
        default:
            ejecutaCasoPorDefecto();
    }
    
  • Bucles. Respetaremos los espaciados y diferencias de bloques funcionales.

    while (condicion) {
     //- Código...
    }
    

 

BUENAS PRÁCTICAS

Ni que decir tiene que hay que seguir una serie de pautas para que nuestro proyecto cumpla los estándares de calidad y pueda pasar herramientas como SonarQube sin ningún tipo de problemas.

  • Saltos de línea. Es importante no abusar de los saltos de líneas y ponerlos siempre siguiendo unas pautas.
    Ej: En los patrones Builder después del operador “.”, en las condiciones después de “&&” o “||”, etc.
  • Uso de this. Lo usaremos sólo para salvar ambigüedades.

    public class A {
        private String mName;
        public boolean selected;   
     
     
        A (String name, Boolean selected) {
            mName = name;
            this.selected = selected;
        }
     
     
        public void setSelected(boolean selected) {
            this.selected = selected;
        }
    }

 

TRATAMIENTO DE EXCEPCIONES O FLUJOS INCOHERENTES

Nuestro código tiene que ser seguro, por ello, debemos controlar todas las excepciones y tener una app libre de crashes. Además debemos seguir una nomenclatura para el reporte de las excepciones cuando se usan herramientas de log de crashes, de esta forma serán más fáciles de solventar.

 

¿NUESTRO CÓDIGO NECESITA COMENTARIOS?

En principio no, ya que los nombres de los métodos y variables serán autodescriptivos. Además los métodos serán atómicos, consiguiendo que cada función haga una única tarea y pudiendo así entender qué se está haciendo y por qué con un primer vistazo. No obstante, podemos añadir comentarios para aclarar ciertas partes del código vinculados a la lógica de negocio con el fin de facilitar su comprensión.

 

EJEMPLO DE USO

A continuación vamos a ver un ejemplo muy simple de su aplicación:

Antes de aplicar Code Style:

//- Código aglutinado y de difícil lectura
	if(condicionA&&condicionB&&(condicionC||condicionD))
			//- Código

Después de aplicar Code Style:

boolean condicionE = condicionC ||
                        condicionD;
						
	//- Correcto espaciado y salto de líneas
	if (condicionA &&
			condicionB &&
			condicionE) {
		//- Código
	}

 

En resumen, aunque en un principio pueda parecer un engorro consensuar o llegar a un acuerdo sobre su uso, gracias al Code Style escribiremos un código que simplificará tanto nuestro trabajo como el de nuestros compañeros.


Uso de cookies

Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continúas navegando estas dando tu consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pincha el enlace para obtener más información.

ACEPTAR
Aviso de cookies