Jakarta EE: Aplicación monolitica con Java Server Faces.

Con el auge de los microservicios se podria pensar que el tipo aplicaciones monolitcas, ntier, hibridas o distribuiridas estan muertas, pero no es así, estas aun tienen una gran parte del mercado y son una solucion viable, sobre todo para aplicaciones pequeñas , empresas pequeñas, startups o midlewares medianos.

¿que es una aplicación monolitica?

Una aplicacion monolitica es aquella cuyos componentes estan estrechamente ligados de tal forma que cada uno de las clases o archivos dependen uno del otro. Una aplicacion monolitica puede estar formada por 1 o cientos de archivos en una sola carpeta, y para poder hacer funcionar se requieren todo los archivos o componente, logicamente representan toda la solución, en Java, son entregados en un archivo JAR , WAR o EAR.

¿Que es Java Server Faces?

JavaServer Faces (JSF) es un framework de desarrollo de aplicaciones web Java que se utiliza para simplificar la creación de interfaces de usuario en aplicaciones web utilizando el concepto llamado: Server side render.

¿que es “Server-Side Rendering” (SSR)?

Es una técnica utilizada en el desarrollo web para generar y renderizar contenido web en el servidor antes de enviarlo al navegador del usuario. A diferencia de las aplicaciones de representación del lado del cliente (Client-Side Rendering o CSR), donde la mayor parte del procesamiento y la renderización ocurre en el navegador del cliente, en SSR, gran parte de este trabajo se realiza en el servidor.

Esto tiene la notable ventaja que los componentes visuales pueden serreutilizados , ademas permite al equipo de desarrollo centrarse en la logica de negocio y no en la apariencia, permitiendo acelerar el desarrollo y simplicar el mantenimiento.

Esta tecnologia fué un BOOM en el 2005 al 2015, actualmetne con el auge de las apliaciones distribuidas, los microservicios y los servicios rest que permitieron la proliferacion de los frameworks javascript estan cada vez en menos uso, pero son bien apreciados en muchas empresas.

Frameworks que utilizan SSR

  • JavaServer Faces (JSF): es un marco de desarrollo web Java que permite la creación de aplicaciones web con representación del lado del servidor.
  • Thymeleaf: Thymeleaf es un motor de plantillas Java que permite la creación de páginas web con representación del lado del servidor. Es especialmente popular en combinación con el marco Spring.
  • Spring Boot: Si está utilizando Spring Boot como su marco de desarrollo, puede implementar SSR combinando Spring Boot con Thymeleaf u otras tecnologías de plantillas.
  • JSP (JavaServer Pages): JSP es una tecnología de Java EE que permite la creación de páginas web dinámicas con representación del lado del servidor. Aunque se ha vuelto menos popular en comparación con otras tecnologías de plantillas, todavía se utiliza en algunas aplicaciones Java legadas.
  • Vaadin: Vaadin es un marco de desarrollo de aplicaciones web en Java que ofrece una interfaz de usuario rica y permite la representación del lado del servidor. Es especialmente útil para aplicaciones empresariales.

Librerias Java Server Faces

  1. PrimeFaces: PrimeFaces es una biblioteca de componentes de código abierto muy popular para JSF. Ofrece una amplia variedad de componentes ricos y temas personalizables para mejorar la apariencia y la funcionalidad de las aplicaciones JSF.
  2. RichFaces: RichFaces es otra biblioteca de componentes para JSF que proporciona componentes AJAX ricos y herramientas para mejorar la experiencia del usuario en aplicaciones web JSF.
  3. BootsFaces: BootsFaces combina JSF con Bootstrap, el popular framework de diseño web, para facilitar la creación de aplicaciones web modernas y receptivas con JSF.
  4. IceFaces: IceFaces es una biblioteca de componentes JSF que se centra en proporcionar funcionalidad AJAX avanzada para aplicaciones JSF, lo que permite una experiencia de usuario rica y dinámica.
  5. Apache MyFaces: MyFaces es un proyecto de código abierto de la Apache Software Foundation que ofrece una implementación de JSF. Incluye un conjunto de componentes y herramientas para el desarrollo de aplicaciones JSF.
  6. OmniFaces: OmniFaces es una biblioteca de utilidades que complementa JSF y resuelve diversos problemas comunes en el desarrollo de aplicaciones JSF. Ofrece un conjunto de extensiones útiles.
  7. Mojarra (Oracle JSF Reference Implementation): Mojarra es la implementación de referencia de JSF proporcionada por Oracle. Aunque es una implementación estándar de JSF, se utiliza comúnmente en aplicaciones JSF.
  8. Cuban Platform: Cuban Platform es un conjunto de herramientas y bibliotecas que extienden JSF y otros marcos de Java para el desarrollo de aplicaciones empresariales.

En este articulo vamos a trabajar con PrimeFaces.

https://primefaces.org/showcase/index.xhtml?jfwid=c972f

Creando aplicación web empresarial paso a paso:

Se puede comenzar a crear la aplicacion desde el website de jakarta o desde el IDE. El startup de jakarta nos permite una gran configuracion inicial para nuestro proyecto.

  1. Crear el proyecto, para esto utilizaremos IntelliJIDEa

Codigo del ejercicio:

El codigo del ejercicio lo pueden encontrar en github del grupo:

https://github.com/berroteran/demoJakarta10JSF

Posibles problemas y soluciones.

Referencias:

https://blog.payara.fish/getting-started-with-jakarta-ee-9-jakarta-faces-jsf

https://blog.payara.fish/a-quick-look-at-faces-jsf-4.0-in-jakarta-ee-10

https://github.com/eclipse-ee4j/mojarra

https://primefaces.github.io/primefaces/12_0_0/#/?id=main

Ejemplos que te pueden ser utiles:

https://github.com/aturanj/java-jakarta-primefaces


Crear un archivo EAR usando MAVEN

En el STACK java existe un archivo EAR que no es mas que un archivo ZIP con una estructura especifica. EAR (Enterprise Application aRchive) /

Un EAR normalmente contiene 2 archivos contenedores mas, un WAR (Web Archive) y un EJB , un archivo que contiene los EJB, sin embargo puede contener muchos mas (técnicamente no tiene limites), incluyendo clientes de EJB, EJB locales, pero el mínimo de todo EAR es uno, un modulo o contenedor, el cual puede ser un WAR o un EJB.

Prerequisitos

Java 1.4, Maven 3.6.3

Creando el proyecto vía comando.

mvn archetype:generate -DgroupId=com.ejemplo.demo.ear -DartifactId=simple-ear -DarchetypeArtifactId=wildfly-javaee7-webapp-ear-archetype -DarchetypeGroupId=org.wildfly.archetype -DinteractiveMode=false

Usando el archetype “maven-archetype-quickstart”

$ mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
-DarchetypeArtifactId=maven-archetype-quickstart \
-DarchetypeVersion=1.4 \
-DgroupId=mtitek.maven.ear.samples \
-DartifactId=mtitek-maven-ear-samples \
-Dpackage=mtitek.maven.ear.samples \
-Dversion=1.0.0-SNAPSHOT \
-DinteractiveMode=false

Donde se usa un EAR

Actualmente dada la gran popularidad de Spring-Boot casi no se ven EAR, pero en el otro lado, fuera de spring-boot, en los servidores empresariales como: JBOSS, websphere, Apache TomEE, Wildfly.

Ejemplo de un proyecto EAR

Creando el EAR usando JetBrains IntelliJ IDEa

Usando el IDE para crear el proyecto gráficamente.

Creando un proyecto, paso uno.

Click en Crear.

Así queda el proyecto y puede eliminar a su gusto.

Referencias

  • https://en.wikipedia.org/wiki/EAR_(file_format)
  • https://maven.apache.org/plugins/maven-ear-plugin/
Configuración y puesta en marcha de servidor WildFly 26 Server

Configuración y puesta en marcha de servidor WildFly 26 Server

Wildlfly es de los servidores mas usados en aplicaciones empresariales java, es muy potente, configurable, digno heredero de JBOSS, con muchos features, sin ser complicado. (Excepto features avanzados)

1. Descargar

Lo primero es descargar el programa, lo puedes hacer en este link:

https://www.wildfly.org/downloads/

Opciones de descarga

La opción que generalmente se descarga es la full EE y distribución web, sea para windows o para linux.

En windows el contenedor ZIP es el mas común, para Linux: tgz.

La versión preview se usa para pruebas, aun no recomendable para un ambiente de producción.

2. Configurar

Una vez descargado y «descomprimido», se puede iniciar Wildfly, pero aun no está listo para usarse.

Para poder desplegar nuestras aplicaciones es necesario poder acceder a la consola, la consola administrativa solo se accede desde la versión FULL descargada, las version “Servlet-Only Distribution” se usa para servidores esclavos o gestionados en dominio.

2.1 Agregar usuarios.

Lo primero es crear uno o mas usuarios administrativos, aunque se pueden editar los archivos, se recomienda usar las herramientas creadas para ello, en windows son archivos batch(.bat) y en linux shell script (.sh).

Comandos de Wildfly

En la carpeta “bin” están los comandos para gestionar el servidor.

./add-user.sh
Dejar en blanco para los grupos inicialmente.
Contestar yes para terminar de agregar el usuario.

3. Iniciar

Para iniciar el servidor la forma mas común es “standalone” la otra opción es via “dominio”, esta es para cundo tengamos un cluster de servidores.

 ./standalone.sh 

Listo, ya tenemos iniciado el servidor sirviendo las aplicaciones en el puerto 8080, y la consola administrativa en el 9990, con esto ya podemos instalar las aplicaciones web que sea necesario sea archivo WAR o EAR.

Para entrar a la consola administrativa usa el siguiente link:

http://192.168.30.216:9990/console/index.html

Ventana de inicio de sesión.

Opciones para desplegar aplicaciones

.

Opción para cargar una aplicación web java.

Primeros pasos con Gradle en proyectos Java

¿Ya haz escuchado de Gradle? si haz creado o intentado crear un aplicacion en Android de seguro que sí, y es probable que te dé dolores de cabeza, que no quieras ni tocarlo. Si es así, entonces lo mejor es entenderlo, comprenderlo, asimilarlo. Es por eso que te traemos este artículo para que domines al mamut! (Elefante).


Project Tools Estadisticas
Comparativa de uso de Maven vs Gradle según encuesta 2020.

Contenido.

Introducción.
¿Qué es Gradle?
Instalación.
Primeros pasos con Gradle.
Creando nuestro primer proyecto Java.
Otro proyecto Java con Gradle.

Introducción.

Desde la clásica herramienta ‘make’ de los años 70, la tecnología de los sistema de construcción de proyectos ha ido mejorando día a día. En donde algunos están enfocados a ciertos aspectos de la construcción, otros tratan de abarcar la plenitud de los procesos de construcción de proyecto: compilación, manejo de dependencias, integración continua, automatización del proceso de construcción, etc.,  entre los cuales tenemos a Ant, Maven y Gradle.

¿Qué es Gradle?

Gradle es la nueva generación de herramientas de construcción automatizadas de proyectos, diseñado para superar las limitaciones de Maven. Gradle es software libre diseñado para construcciones multi-proyecto los cuales pueden pueden llegar a ser caóticos. Gradle basa la construcción de proyectos en algunos conceptos de Apache Ant y Apache Maven, cambiando la configuración de forma XML, a un lenguaje específico de dominio (Kotlin DSL). También utiliza un grafo acíclico dirigido (DAG) para determinar la secuencia en que se construirá el proyecto. Ver mas en Wikipedia

¿Qué es un lenguaje específico de dominio (DSL)?

Es un lenguaje de programación que provee una técnica para resolver un problema en específico (¿Quieres saber más?) . En el caso de Gradle utiliza sentencias de Groovy y Kotlin para la construcción de proyectos de software.

¿Qué es un grafo acíclico dirigido (DAG)?

Es un grafo que no sigue una secuencia lineal: no se sigue un camino directo o orden secuencial. ¿Quieres saber mas?.

Algunas características

  •  Depuración colaborativa: Permite compartir los resultados de la compilación para resolver en equipo de forma eficiente posibles problemas que aparezcan.
  •  Construcción incremental: Valida en el proceso de compilación si la entrada, salida o implementación de una tarea ha cambiado. En caso de no existir algún cambio la considera actualizada y no se ejecuta.
  •  Diseño de repositorio personalizado: Podremos tratar prácticamente cualquier estructura de directorios del sistema de archivos como un repositorio de Artifacts.
  •  Dependencias transitivas: Es uno de los principales beneficios que ofrece al utilizar la gestión de dependencias ya que se encarga de descargar y administrar las dependencias transitivas.
  •  Soporte a Groovy y Scala incorporado: Compatibilidad con los proyectos de Groovy, permitiendo trabajar con código Groovy o código Scala e inclusive desarrollar código mixto Java y Groovy o Java y Scala.
  •  Compilación incremental para Java: En caso de que el código fuente o la ruta de clase cambien, Gradle cuenta con la capacidad para detectar todas las clases que se vean afectadas por dicho cambio y procederá a recompilarlas.
  •  Embalaje y distribución de JAR, WAR y EAR: Cuenta con herramientas para empaquetar el código basado en JVM (Java Virtual Machine) en archivo comunes.
  •  Integración con Android Studio: Android Studio no cuenta con un generador interno, sino que delega todas las tareas de compilación en Gradle, garantizando la corrección en todas las construcciones, ya sea que se ejecuten desde Android Studio, la línea de comandos o un servidor de construcción de integración continua.
  •  Soporte de MS Visual C ++ y GoogleTest: Gradle acepta la construcción con el compilador de Visual C de Microsoft en Windows. (VS 2010, VS 2013 y VS 2015 compatibles), así como también realizar pruebas de aplicaciones C con GoogleTest.

NOTA: Para los ejemplos de este artículo utilizaremos Gradle con DSL basado en Groovy.

Instalación.

Pre-instalación (Requisitos)

Para poder ejecutar Gradle es necesario tener instalado JDK 8 o superior. Comencemos verificando la versión de Java que tenemos instalado, ejecutando la siguiente instrucción:

java -version

veremos algo así:

openjdk version "11.0.5" 2019-10-15
OpenJDK Runtime Environment (build 11.0.5+10-post-Debian-2)
OpenJDK 64-Bit Server VM (build 11.0.5+10-post-Debian-2, mixed mode, sharing)

En el caso de no tener instalado JDK procedemos a su instalación.

Instalación de OpenJDK en distribuciones GNU/Linux.

En casi todas las distribuciones GNU/Linux el paquete JDK se encuentra en los repositorios oficiales:

Debian: sudo apt update && sudo apt-get install openjdk-11-jdk
Fedora: sudo dnf install java-11-openjdk

Instalación de OpenJDK en sistema operativo Windows.


Ver Tutoral Instalar Java(OpenJDK) en Windows

Instalación Manual  de Gradle.

En los repositorio de distribuciones GNU/Linux se encuentran versiones de Gradle que podemos instalar, pero la documentación oficial nos sugiere instalar desde la página oficial. Los pasos de la instalación que mostraremos en este artículo están basados en la documentación oficial:

  1. Descargamos los binarios desde la página oficial de Gradle.
  2. Creamos una carpeta(directorio) donde almacenaremos los binarios.
    En distribuciones GNU/Linux:

    sudo mkdir /opt/gradle 

    En sistema Windows:

    md c:gradle 
  3. Descomprimimos el archivo que contiene los binarios. Luego se copian a la carpeta creada.
  4. Se agrega al sistema la ubicación de los binarios.
    En distribuciones GNU/Linux:

    export PATH=$PATH:/opt/gradle/gradle-6.0.1/bin 

    En sistema Windows:

    set PATH=%PATH%;%c:gradlegradle-6.0.1%bin 
  5. Verificamos la instalación.
    gradle -v
    ------------------------------------------------------------
    Gradle 6.0.1
    ------------------------------------------------------------
    

Gradle en los IDEs.

En algunos IDEs, como Eclipse 2019-9, Netbeans 11.2 y IntelliJ IDEA 2019.2,  cuentan con integración para trabajar con Gradle, a continuación veremos imágenes de cómo podemos crear proyectos con Gradle desde los IDEs.

Primeros pasos en Gradle, proyecto en Netbeans

Gradle – Netbeans

Primeros pasos en Gradle - proyecto en IntelliJ IDEA

Gradle IntelliJ IDEA

Primeros pasos en Gradle - proyecto en Eclipse

Gradle – Eclipse

Gradle en el Market Place de Eclipse

Gradle en el Market Place de Eclipse.

Primeros pasos con Gradle.

¿Cómo se organiza la construcción en Gradle ?

Gradle se organiza en proyectos y tareas, en donde los proyectos puede ser un producto de lo que te encuentres haciendo, como una librería jar, una aplicación web o un archivo ZIP de distribución, etc. . Cada proyecto está compuesto por una o más tareas.

Las tareas representan la parte atómica en una construcción. Gradle proporciona una biblioteca de tareas, donde cada tarea realiza alguna operación básica, como compilar, ejecutar jar, copiar archivos, crear archivos jar, entre otras.

Ente las tareas de la biblioteca Gradle encontramos la herramientas para listar los proyectos y tareas. Para ello, desde una terminal digitamos la siguiente sentencia:

Listar tareas

gradle -q tasks
------------------------------------------------------------
Tasks runnable from root project
------------------------------------------------------------
Build Setup tasks
-----------------
init - Initializes a new Gradle build.
wrapper - Generates Gradle wrapper files.
Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'gradle'.
components - Displays the components produced by root project 'gradle'. [incubating]
dependencies - Displays all dependencies declared in root project 'gradle'.
dependencyInsight - Displays the insight into a specific dependency in root project 'gradle'.
dependentComponents - Displays the dependent components of components in root project 'gradle'. [incubating]
help - Displays a help message.
model - Displays the configuration model of root project 'gradle'. [incubating]
outgoingVariants - Displays the outgoing variants of root project 'gradle'.
projects - Displays the sub-projects of root project 'gradle'.
properties - Displays the properties of root project 'gradle'.
tasks - Displays the tasks runnable from root project 'gradle'.
To see all tasks and more detail, run gradle tasks --all
To see more detail about a task, run gradle help --task 

Listar Proyectos

gradle -q projects                                                                       
------------------------------------------------------------
Root project
------------------------------------------------------------
Root project 'gradle'
No sub-projects
To see a list of the tasks of a project, run gradle :tasks
For example, try running gradle :tasks

Nota: La opción -q evita que se visualicen mensajes innecesarios en el proceso de construcción.

Trabajando con tareas.

Vamos ejecutar algunas tareas listadas con la sentencia gradle -q tasks. Como vemos, ya hemos utilizado dos tareas de la lista las cuales son tasks y projects. Ejecutaremos dos tareas más para no hacer tan extenso este artículo, comenzando con ‘help’ y después con la tarea ‘init’.

gradle -q help                                                                           
Welcome to Gradle 6.0.1.
To run a build, run gradle  ...
To see a list of available tasks, run gradle tasks
To see a list of command-line options, run gradle --help
To see more detail about a task, run gradle help --task 
For troubleshooting, visit https://help.gradle.org

De la salida mostrada por la tarea ‘help’ tomaremos la sentencia gradle help –task,  la cual nos mostrará la ayuda de una tarea específica. En el siguiente ejemplo le pediremos a Gradle que  nos muestre información de la tarea ‘init’.

gradle -q help --task init                                                                           
Detailed task information for init
Path
     :init
Type
     InitBuild (org.gradle.buildinit.tasks.InitBuild)
Options
     --dsl     Set the build script DSL to be used in generated scripts.
               Available values are:
                    groovy
                    kotlin
     --package     Set the package for source files.
     --project-name     Set the project name.
     --test-framework     Set the test framework to be used.
                          Available values are:
                               junit
                               junit-jupiter
                               kotlintest
                               scalatest
                               spock
                               testng
     --type     Set the type of project to generate.
                Available values are:
                     basic
                     cpp-application
                     cpp-library
                     groovy-application
                     groovy-gradle-plugin
                     groovy-library
                     java-application
                     java-gradle-plugin
                     java-library
                     kotlin-application
                     kotlin-gradle-plugin
                     kotlin-library
                     pom
                     scala-library
                     swift-application
                     swift-library
Description
     Initializes a new Gradle build.
Group
     Build Setup

Ahora que ya sabemos que la tarea ‘init’ crea la estructura inicial de directorio en nuestro proyecto y  además nos brinda las opciones que tenemos para ejecutar la tarea init, procederemos desde una terminal a ejecutar:

gradle init --project-name myproyect --type basic
Select build script DSL:
1: Groovy
2: Kotlin
Enter selection (default: Groovy) [1..2] 
> Task :init
Get more help with your project: https://guides.gradle.org/creating-new-gradle-builds
BUILD SUCCESSFUL in 11s
2 actionable tasks: 1 executed, 1 up-to-date

Hablaremos un poco de la sentencia que utilizamos para ejecutar la tarea init. Como vemos, utilizamos algunas de las opciones que nos mostró la tarea help –task init, de las cuales detallamos a continuación:

–project-name : con esta opción le indicamos a Gradle cómo se llama nuestro proyecto.

–type: con esta opción le indicamos a Gradle el tipo de estructura de directorio a construir.

Cómo pueden ver en el ejemplo anterior, Gradle nos pide que le indiquemos el DSL que va utilizar, por defecto Gradle utiliza Groovy, por lo que solo se presiona Enter para que Gradle entienda que debe utilizar DSL basados en Groovy. Hasta ahí todo bien. ¿Pero qué obtuvimos de ejecutar la tarea init?.

Veamos la estructura de directorio.

tree                                                                                          
.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
└── settings.gradle

Una visión general de lo que nos construyó la tarea init con el type basic.

Nos creó dos archivos en la raíz del proyecto con los nombres build.gradle y settings.gradle. Estos archivos son utilizados por Gradle para la configuración de construcción del proyecto.

build.gradle: Archivo de texto plano que mediante del lenguaje específico de dominio(DSL). En este archivo especificamos los tipos de empaquetados y el producto que requerimos al compilar (jar, war, etc). También especificamos los repositorios y dependencias que se necesitarán al momento de compilar. Además, puedes definir propiedades del archivo manifiesto.

settings.gradle: Archivo de texto plano que indica a gradle los módulos que deberá incluir al momento de compilar el proyecto.

También nos creó un directorio Gradle el cual almacena el wrapper. Wrapper es un script que invoca una versión declarada de Gradle, el cual lo descarga si es necesario. Los archivos que componen wrapper son:

gradle-wrapper.jar: El archivo Wrapper JAR que contiene el código para descargar la distribución Gradle.

gradle-wrapper.properties: Un archivo de propiedades responsable de configurar el comportamiento del tiempo de ejecución Wrapper, p. La versión Gradle compatible con esta versión. Tenga en cuenta que las configuraciones más genéricas, como configurar el Wrapper para usar un proxy, deben ir a un archivo diferente.

 gradlew: script para sistemas basado en UNIX, almacenado en el directorio raíz del proyecto para ejecutar gradle-wrapper.

gradlew.bat: script para sistemas Windows, almacenado en el directorio raiz del proyecto para ejecutar gradle-wrapper.

Los scripts gradlew y gradlew.bat son los que recomienda gradle ejecutar con las tareas una vez que se inicializó el proyecto.

Creando nuestra primera tarea – Hola Mundo.

En Gradle no solo contamos con las tareas que vienen en la biblioteca, ya que podemos crear nuestra propias tareas utilizando el DSL.

Con nuestro editor de texto preferido crearemos una archivo build.gradle y le agregaremos la siguientes linea de código:

task hw { 
	doLast(){ 
		println "Helo Word"
	}
}

Para ejecutar la tarea que acabamos de crear, desde una terminal nos ubicamos en el directorio donde creamos el archivo build.gradle y digitamos

gradle -q hw
Hello Word

Utilizando el grafo acíclico en las tareas (dependencias).

Una de las bondades de Gradle es que podemos determinar el orden en que las tareas se va ejecutando. Para ello necesitaremos del método dependsOn.

Ejemplo 1.

Imagine que tenemos las tareas “A” y “B”, pero la tarea “B” depende que se realice primero la tarea “A”. Veamos con un ejemplo de cómo podemos hacer para que se realice la tarea “A” antes de la tarea “B”.

Editamos el archivo build.gradle que habíamos creado en el ejemplo anterior y nos quedará con el siguiente código:

task hw { 
	doLast(){ 
		println "Helo Word"
	}
}
task whoAmI(dependsOn: hw) {
	doLast(){
		println "I am Gradle"
	}
}

O con el siguiente código:

task hw { 
	doLast(){ 
		println "Helo Word"
	}
}
task whoAmI {
	dependsOn hw
	doLast(){
		println "I am Gradle"
	}
}

Una vez realizadas las modificaciones, ejecutamos la tarea whoami con la siguiente sentencia

task -q whoami 

Creando nuestro primer proyecto Java.

Vamos a crear nuestro primer proyecto “hola mundo” en Java con ayuda de la tarea init de Gradle. Para ello, desde una terminal nos ubicamos en la carpeta donde crearemos nuestro proyecto y ejecutamos la siguiente sentencia:

Primeros pasos con Gradle en proyectos Java

Gradle en proyectos Java

De la sentencia anterior obtendremos la siguiente estructura de directorios:

tree
.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
└── src
    ├── main
    │   ├── java
    │   │   └── ni
    │   │       └── gacssoft
    │   │           └── App.java
    │   └── resources
    └── test
        ├── java
        │   └── ni
        │       └── gacssoft
        │           └── AppTest.java
        └── resources
13 directories, 8 files

Como podemos ver, nos crea una estructura de directorio básicas para trabajar en proyectos desarrollados en Java. Veamos ahora el contenido del archivo build.gradle:

/*
 * This file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Java project to get you started.
 * For more details take a look at the Java Quickstart chapter in the Gradle
 * User Manual available at https://docs.gradle.org/6.0.1/userguide/tutorial_java_projects.html
 */
plugins {
    // Apply the java plugin to add support for Java
    id 'java'
    // Apply the application plugin to add support for building a CLI application.
    id 'application'
}
repositories {
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}
dependencies {
    // This dependency is used by the application.
    implementation 'com.google.guava:guava:28.0-jre'
    // Use JUnit test framework
    testImplementation 'junit:junit:4.12'
}
application {
    // Define the main class for the application.
    mainClassName = 'ni.gacssoft.App'
}

Veremos cada apartado del  build.gradle que nos proporcionó la tarea init, iniciando con el bloque plugins.

Plugins

Con el propósito de dar lo que se necesite en el momento que lo necesite, Gradle brinda en su núcleo pocas herramientas de automatización. Las utilidades que se requieran para la automatización son proporcionadas por medio de complementos (plugins).

Existen dos tipos de complementos(¿Quieres saber mas?): complementos por script y complemento binarios.

Script: son scripts de compilación adicionales que configuran aun más la compilación y generalmente implementan un enfoque declarativo para manipular la compilación.

Binario: son clases que implementan la interfaz del complemento y adoptan un enfoque programático para manipular la compilación.

Para este artículo trabajaremos con los plugins binarios que nos proporciona la tarea init:

//Este bloque le indica a gradle que aplique los complementos que se espesifican dentro los corchtes 
plugins { 
	id 'java' // le indica que utilizaremos el complemento para compilar java
	id 'application' // le indica que utilizaremos el complemento para generar o ejecutar la aplicacion
}

Estos plugins proporcionan tareas adicionales que podemos ejecutar. Listaremos las tareas que tenemos actualmente y veremos que tenemos una diferencia con el listado anterior:

 gradle -q tasks 
executing gradlew instead of gradle
------------------------------------------------------------
Tasks runnable from root project
------------------------------------------------------------
Application tasks
-----------------
run - Runs this project as a JVM application
Build tasks
-----------
assemble - Assembles the outputs of this project.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
classes - Assembles main classes.
clean - Deletes the build directory.
jar - Assembles a jar archive containing the main classes.
testClasses - Assembles test classes.
Build Setup tasks
-----------------
init - Initializes a new Gradle build.
wrapper - Generates Gradle wrapper files.
Distribution tasks
------------------
assembleDist - Assembles the main distributions
distTar - Bundles the project as a distribution.
distZip - Bundles the project as a distribution.
installDist - Installs the project as a distribution as-is.
Documentation tasks
-------------------
javadoc - Generates Javadoc API documentation for the main source code.
Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'java-gradle'.
components - Displays the components produced by root project 'java-gradle'. [incubating]
dependencies - Displays all dependencies declared in root project 'java-gradle'.
dependencyInsight - Displays the insight into a specific dependency in root project 'java-gradle'.
dependentComponents - Displays the dependent components of components in root project 'java-gradle'. [incubating]
help - Displays a help message.
model - Displays the configuration model of root project 'java-gradle'. [incubating]
outgoingVariants - Displays the outgoing variants of root project 'java-gradle'.
projects - Displays the sub-projects of root project 'java-gradle'.
properties - Displays the properties of root project 'java-gradle'.
tasks - Displays the tasks runnable from root project 'java-gradle'.
Verification tasks
------------------
check - Runs all checks.
test - Runs the unit tests.
Rules
-----
Pattern: clean: Cleans the output files of a task.
Pattern: build: Assembles the artifacts of a configuration.
Pattern: upload: Assembles and uploads the artifacts belonging to a configuration.
To see all tasks and more detail, run gradlew tasks --all
To see more detail about a task, run gradlew help --task "task" 

Como podemos ver, el complemento Application nos proporciona la tarea run. Con esta tarea podemos ejecutar el proyecto que hemos creado con la siguiente sentencia:

gradle -q run                         
executing gradlew instead of gradle
Hello world.

Repositories

Sigamos analizando el archivo build.gradle. Ahora veremos el bloque repositories. Cuando trabajamos en proyectos, el 100% del código no lo escribe un solo desarrollador. En muchas ocasiones necesitamos librerías que nos ayudan con la funcionalidad de nuestra aplicación. Este bloque le indica a Maven dónde buscar y descargar las librerías que nuestro proyecto necesita para que funcione:

repositories {//le dice a gradle los repositorios donde buscara las librerias
    jcenter() // le indica a gradle el repositorio donde ira a buscar las librerias necesarias para el proyecto
}

Entre los repositorios populares, Gradle tiene asignado los siguientes DSL :

Respositorio                 DSL

Bintray JCenter   ->    jcenter()

Maven Central     ->    mavenCentral()

Google Android  ->     google()

La tarea init agrega en el repositorio Bintray (JCenter). Nosotros podremos cambiar el repositorio o combinarlos.  ¿Quieres saber mas?

Dependencies.

En este bloque de código le indicamos a Gradle las dependencias que necesitará nuestra aplicación para funcionar.  Las dependencias podrán ser utilizadas en tiempo de ejecución o para compilar. La configuración dependerá en algunos caso del complemento (plugin). Por ejemplo, el complemento de Java utiliza las configuraciones implementation, testImplementation, compileOnly, etc. . ¿Quieres saber mas?

dependencies {
    implementation 'com.google.guava:guava:28.0-jre'
    testImplementation 'junit:junit:4.12'
}

Application

En este bloque se asignan valores a las propiedades del complemento Application. Para este ejemplo se utiliza la propiedad mainClassName. Esta propiedad le dice a Gradle que escriba en el archivo de manifiesto el nombre de la clase principal, para que en el momento de ejecutar el proyecto JVM pueda saber cuál es la clase que inicia la aplicación:

application {
    mainClassName = 'ni.gacssoft.App'
}

Ahora que ya tenemos una idea del contenido del archivo de configuración build.gradle, vamos hacer unos cambios. Vamos a mejorar el “hola mundo” utilizando la libreria jfiglet. Para ello le diremos a Gradle que busque en los repositorio de mavenCentral.

repositories {
	mavenCentral()
}
Primeros paso en gradle- mavenCentral

Gradle- mavenCentral

Buscamos en el repositorio de Maven la versión más actual de la librería.

Primeros pasos en gradle-mavenCentral

Elegimos la versión 0.0.8, copiamos las especificaciones de la dependencia para Gradle.

Primeros pasos en gradle-mavenCentral libreria jfiglet

mavenCentral librería jfiglet

dependencies {
    // This dependency is used by the application.
        implementation 'com.google.guava:guava:28.0-jre'
    compile group: 'com.github.lalyos', name: 'jfiglet', version: '0.0.8'
	// Use JUnit test framework
    testImplementation 'junit:junit:4.12'
}

Para la versión 6 de Gradle, podemos utilizar un formato más corto para las dependencias, tal como especifica la dependencia de guava. Entre comillas simple especificamos ‘grupo:name:version’, lo que nos quedaria ‘com.github.lalyos:jfiglet:0.0.8’

Como  no estamos utilizando guava y junit en este proyecto, los pondremos como comentario para que Gradle los ignore al momento de compilar y nos queda así:

dependencies {
    // This dependency is used by the application.
    //    implementation 'com.google.guava:guava:28.0-jre'
    implementation 'com.github.lalyos:jfiglet:0.0.8'
compile group: 'com.github.lalyos', name: 'jfiglet', version: '0.0.8'
// Use JUnit test framework
    //testImplementation 'junit:junit:4.12'
}

Ahora vamos a modificar el código de nuestro proyecto, específicamente la clase App.java y la dejaremos así:

/*
 * This Java source file was generated by the Gradle 'init' task.
 */
package ni.gacssoft;
import com.github.lalyos.jfiglet.FigletFont;
import java.io.IOException;
public class App {
    public String getGreeting() {
        return "Hello world.";
    }
    public static void main(String[] args) throws IOException {
        String whoAmI = FigletFont.convertOneLine("JAVA");
        System.out.println(new App().getGreeting());
        System.out.println( "Yo soy ...." );
        System.out.println( whoAmI );
    }
}

Una vez que tengamos guardado los cambios lo ejecutamos con la tarea run.

Primeros pasos con gradle- task run

Gradle – task run (Esto es una consola en Linux)

Hasta aquí nuestro proyecto Hola Mundo en Java construido, compilado y ejecutado con Gradle. El código se encuentra disponible en Github.


Ver Código en Githhub

Otro proyecto Java con Gradle.

Ahora, vamos a crear otro proyecto en Java utilizando Gradle, pero esta vez agregando un poco más de complejidad que el proyecto “hola mundo“. Para este ejemplo utilizaré el código del artículo Persistencia de datos implementando JDBC  .

Creando la estructura de directorios.

Utilizando Gradle digitamos desde la terminal la siguiente instrucción:

gradle -q init  --project-name jdbcsqlite --type java-application
Select build script DSL:
  1: Groovy
  2: Kotlin
Enter selection (default: Groovy) [1..2] 1
Select test framework:
  1: JUnit 4
  2: TestNG
  3: Spock
  4: JUnit Jupiter
Enter selection (default: JUnit 4) [1..4] 1
Source package (default: jdbcsqlite): ni.gacssoft 

Nos quedará la siguiente estructura de directorios:

tree
.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
└── src
    ├── main
    │   ├── java
    │   │   └── ni
    │   │       └── gacssoft
    │   │           └── App.java
    │   └── resources
    └── test
        ├── java
        │   └── ni
        │       └── gacssoft
        │           └── AppTest.java
        └── resources
13 directories, 8 files

Crearemos las carpetas controller, view y model dentro de la carpeta main/java/ni/gacssosft/

mkdir main/java/ni/gacssoft/util 
mkdir main/java/ni/gacssoft/controller 
mkdir main/java/ni/gacssoft/view 
mkdir main/java/ni/gacssoft/model

Modificación el build.gradle

Modificaremos el archivo build.gradle, que nos generó la tarea init:

/*
 * This file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Java project to get you started.
 * For more details take a look at the Java Quickstart chapter in the Gradle
 * User Manual available at https://docs.gradle.org/6.0.1/userguide/tutorial_java_projects.html
 */
plugins {
    // Apply the java plugin to add support for Java
    id 'java'
    // Apply the application plugin to add support for building a CLI application.
    id 'application'
}
repositories {
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}
dependencies {
    // This dependency is used by the application.
    implementation 'com.google.guava:guava:28.0-jre'
    // Use JUnit test framework
    testImplementation 'junit:junit:4.12'
}
application {
    // Define the main class for the application.
    mainClassName = 'ni.gacssoft.App'
}

Primero, agregamos la dependencia para el driver de SQLite.

dependencies {
    // This dependency is used by the application.
    implementation 'com.google.guava:guava:28.0-jre'
    // Use JUnit test framework
    testImplementation 'junit:junit:4.12'
    implementation 'org.xerial:sqlite-jdbc:3.28.0'
}

Como siguiente paso, especificamos a Gradle que estamos trabajando con la versión de Java 11:


sourceCompatibility = 11
targetCompatibility = 11

Si hemos trabajado con Maven, tendremos un repositorio local el cual podremos especificar a Gradle que busque dependencia en local agregando el DSL mavenLocal.

repositories {
	mavenLocal()
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}

Como estamos utilizando el código del articulo artículo Persistencia de datos implementando JDBC, necesitamos hacer los siguientes pasos antes de compilar:
1. Crear una carpeta llamada var/db/

mkdir var
mkdir var/db

2. Indicarle a Gradle que los archivos de distribución de la aplicación debe agregar la carpeta var/db/, el cual podemos hacer de la siguiente manera:
Creamos una carpeta dist/ dentro de la carpeta src/, y dentro de la carpeta dist/ creamos las carpetas var/db/.

mkdir src/dist
mkdir var
mkdir var/db

La estructura de directorio nos quedaría:

tree              
.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
├── src
│   ├── dist
│   │   └── var
│   │       └── db
│   ├── main
│   │   ├── java
│   │   │   └── ni
│   │   │       └── gacssoft
│   │   │           ├── App.java
│   │   │           ├── ConnectionBD.java
│   │   │           ├── controller
│   │   │           │   └── PersonaController.java
│   │   │           ├── model
│   │   │           │   └── Persona.java
│   │   │           ├── util
│   │   │           │   └── Input.java
│   │   │           └── view
│   │   │               ├── DeletePersona.java
│   │   │               ├── EditPersona.java
│   │   │               ├── ListPersona.java
│   │   │               └── NewPersona.java
│   │   └── resources
│   └── test
│       ├── java
│       │   └── ni
│       │       └── gacssoft
│       │           └── AppTest.java
│       └── resources
└── var
    └── db

3. Por último para poder ejecutar el proyecto con la tarea run, utilizando la entrada estándar con la Scanner, debemos agregar la siguiente configuración en nuestro archivo build.gradle

run{
    standardInput = System.in
}

Entonces el archivo build.gradle nos quedará de la siguiente manera:

/*
 * This file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Java project to get you started.
 * For more details take a look at the Java Quickstart chapter in the Gradle
 * User Manual available at https://docs.gradle.org/6.0.1/userguide/tutorial_java_projects.html
 */
plugins {
    // Apply the java plugin to add support for Java
    id 'java'
    // Apply the application plugin to add support for building a CLI application.
    id 'application'
}
sourceCompatibility = 11
targetCompatibility = 11
repositories {
	mavenLocal()
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}
dependencies {
    // This dependency is used by the application.
    implementation 'com.google.guava:guava:28.0-jre'
    // Use JUnit test framework
    testImplementation 'junit:junit:4.12'
    implementation 'org.xerial:sqlite-jdbc:3.28.0'
}
application {
    // Define the main class for the application.
    mainClassName = 'ni.gacssoft.App'
}
run{
    standardInput = System.in
}

Ejecutando la aplicación

Primeros pasos con gradle run jdbcsqlite

Hasta aquí hemos dado nuestro primeros pasos con Gradle con proyectos en Java. Si vemos nuestra estructura de directorio después de ejecutar la tarea run, tendremos algo así.

tree
.
├── build
│   ├── classes
│   │   └── java
│   │       └── main
│   │           └── ni
│   │               └── gacssoft
│   │                   ├── App.class
│   │                   ├── ConnectionBD.class
│   │                   ├── controller
│   │                   │   └── PersonaController.class
│   │                   ├── model
│   │                   │   └── Persona.class
│   │                   ├── util
│   │                   │   └── Input.class
│   │                   └── view
│   │                       ├── DeletePersona.class
│   │                       ├── EditPersona.class
│   │                       ├── ListPersona.class
│   │                       └── NewPersona.class
│   ├── distributions
│   │   └── jdbcsqlite.tar
│   ├── generated
│   │   └── sources
│   │       └── annotationProcessor
│   │           └── java
│   │               └── main
│   ├── libs
│   │   └── jdbcsqlite.jar
│   ├── scripts
│   │   ├── jdbcsqlite
│   │   └── jdbcsqlite.bat
│   └── tmp
│       ├── compileJava
│       └── jar
│           └── MANIFEST.MF
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
├── src
│   ├── main
│   │   ├── java
│   │   │   └── ni
│   │   │       └── gacssoft
│   │   │           ├── App.java
│   │   │           ├── ConnectionBD.java
│   │   │           ├── controller
│   │   │           │   └── PersonaController.java
│   │   │           ├── model
│   │   │           │   └── Persona.java
│   │   │           ├── util
│   │   │           │   └── Input.java
│   │   │           └── view
│   │   │               ├── DeletePersona.java
│   │   │               ├── EditPersona.java
│   │   │               ├── ListPersona.java
│   │   │               └── NewPersona.java
│   │   └── resources
│   └── test
│       ├── java
│       │   └── ni
│       │       └── gacssoft
│       │           └── AppTest.java
│       └── resources
└── var
    └── db
        └── mybd.db
40 directories, 31 files

Cómo podemos ver en el directorio build tenemos una carpeta llamada distributions/, y dentro de distributions tenemos un archivo con extensión .tar. En este archivo tenemos nuestro proyecto empaquetado para distribuirlo listo para ejecutar.

La tarea build nos facilita dos tipos de archivos empaquetado, uno con extensión .tar y otro con extensión .zip.

Primeros pasos con gradle - build

Este empaquetado es realizado por el plugin application a través de un complemento interno llamado distribution(¿Quieres saber mas?).

Primeros pasos en gradle - archivo zip

Contendido de archivo zip

Hasta aquí este articulo espero que sea de utilidad para iniciar a construir sus proyectos Java con Gradle. Déjame saber en los comentarios si tienes alguna duda, que te pareció el articulo, y de mas te gustaria aprender.

Introducción a GitFlow, primeros pasos.

Introducción.

Es muy probable que en nuestra vida como desarrolladores de software hayamos tenido que implementar un sistema para gestionar el antes y el después de nuestro proyectos. Con los sistemas de control de versiones nos evitamos la pérdida de tiempo y recursos en implementar un sistema que nos ayude en el tiempo con el desarrollo de aplicaciones. En este artículo veremos una introducción a GitFlow, y daremos nuestros primeros paso en un sistema de control de versiones.

¿Qué es un sistema de control de versiones?

Un sistema de control de versiones es una herramienta que nos ayuda a gestionar en el tiempo los cambios que se realizan en un archivo o conjunto de archivos de un proyecto de software, de modo que podamos recuperar un cambio específico.

Existen muchos sistema de control de versiones. Entre los más utilizados tenemos CVS, Subversion, Mercurial, Git y Bazaar. Para este artículo veremos Git en las exensiones de GitFlow.

¿Qué es Git?

Es un software de control de versiones, que proporciona herramientas para llevar registro de los cambios en archivos de un computador y coordina el trabajo que varias personas realizan sobre archivos compartidos. Diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del control de versiones, de proyectos de desarrollo de software, cuando éstos tienen muchos archivos de código fuente. ¿Quieres saber más?

¿Qué es GitFlow?

Vincent Driessen  presentó en su blog un modelo. Es un modelo de flujo de trabajo ramificado, que asigna roles a un conjunto de ramas y define cómo deben interactuar entre ellas. Actualmente este modelo se presenta en un conjunto liviano de herramientas para el control de versiones con Git, que proveen comandos para gestionar ramas, el cual se denomina Git Flow.

Modelo GitFlow

Modelo Git Flow

¿Cómo instalar GitFlow?

Ahora veremos como instalar GitFlow en los sistema operativo Linux, Mac y Windows.

Sistemas Linux.

En sistemas Linux podemos instalar GitFlow desde la terminal con la siguiente sentencia:

Debian

sudo apt install git-flow

Fedora

sudo dnf install gitflow

Sistema Mac OS X.

Al igual que en sistemas Linux, instalar git flow en Mac OS X es muy fácil. Digitamos una terminal la siguiente sentencia:

 brew install git-flow

O

port install git-flow

 

Sistema Windows

En sistema windows podemos instalar Git Flow, instalando Git para Windows, ya que viene incluido por defecto en el instalador de Git de Windows.

Entendiendo el Modelo de Git Flow.

Como ya sabemos, Git Flow es un modelo de control de flujo ramificado. Su control es basado en ramas, teniendo dos ramas principales y tres ramas auxiliares, de las cuales hablaremos a continuación.

Ramas Principales

El modelo de Git Flow está basado en dos ramas principales infinitas en el tiempo. En estas ramas no se podrá hacer modificaciones directas, recibiendo los cambios solo de sus ramas auxiliares. Las ramas principales son:

  • Master -> Rama principal de producción.
  • Develop -> Rama principal de desarrollo.

Ramas Auxiliares

En el modelo de Git Flow existen tres ramas auxiliares, las cuales se encargan de agregar los cambios a las ramas principales.  Estas son las ramas auxiliares:

  • Feature -> se utiliza para agregar nuevas características al proyecto en desarrollo.
  • Release -> se utiliza para agregar nuevas versiones a producción.
  • Hotfix -> se utiliza para corregir fallas menores que se detectaron en producción.

Todas las etiquetas de las ramas principal y auxiliares pueden ser modificas. Se recomienda utilizar las predeterminadas de Git Flow (master, develop, feature, release y hotfix). Como ejemplo, podríamos utilizar la rama master con la etiqueta producción. Estas etiquetas se pueden modificar al momento que inicia el control de versión con git flow.

Agregando cambios a las ramas Principales

Como ya mencionamos, las ramas principales solo reciben cambios de sus ramas auxiliares, donde master recibe cambios de las ramas release y hotfix. De manera similar, la rama develop recibe los cambios de las ramas feature, release y hotfix.

Para ver cómo se agregan los cambios, utilizaremos como ejemplo el proyecto creado en Persistencia con Sqlite implementando JDBC.

 

Iniciamos el Control de Versión.

Iniciamos el proyecto con Maven. Creamos las carpetas controller, view y model y después cambiamos el contenido del pom.xml. Luego iniciamos el control de versión con git flow con la siguiente sentencia desde una terminal:

git flow init

git flow init

git flow init

Para entender un poco mejor, se cambiaron las etiqueta de master por producción y develop por desarrollo. Sin embargo, se recomienda utilizar las predeterminada por el modelo de GitFlow.

Una vez que iniciamos el control de versiones, git flow habrá trasladado a  la rama de desarrollo como se muestra en la imagen anterior y además habrá creado nuestro primer commit.

Initial commit

Creando las Ramas Feature.

git flow feature

Feature

Como podemos ver en la imagen Feature, esta rama parte de la rama desarrollo (develop) y una vez finalizado, retorna a la rama desarrollo (develop).

Siguiendo con el ejemplo tomando el proyecto de Persistencia con Sqlite implementando JDBC. vamos a crear una feature con el nombre de “connection” con la siguiente sentencia:

git flow feature start connection

Se crea la clase ConnectionBD y se crea el directorio ../var/db, agregamos los cambios al repositorio con los siguientes comando de git

git add .
git commit -m "Se agrega conexion a la base de datos"

Ya agregado el cambio en la rama connection enviaremos el cambio a la rama principal de feature con la siguiente sentencia:

git flow feature finish connection

Git flow feature Una vez que los cambios estén en desarrollo, seguimos los mismos pasos para las demás características que se le agregan al proyecto. Por ejemplo:

git flow feature log

Creando rama Release.

git flow release

Release

La rama Release parte de la rama desarrollo (develop) y traslada los cambios a la rama producción (master)  como una nueva versión del proyecto y a la rama desarrollo (develop) con posibles correcciones detectadas antes de agregar la nueva versión a producción.

Para enviar los cambios de la nueva version a producción (master) lo haremos con los siguientes comando:

Primeramente agregamos la rama auxiliar release:

git flow release start V1.0

Si tenemos fallas detectadas en esta rama, hacemos los commits necesarios, y después enviamos los cambios a producción (master) con el comando:

git flow release finish V1.0

Reparando fallas de producción.

git flow hotfix

Hotfix

La rama auxiliar hotfix se utiliza para corregir fallas que se encontraron en producción (master), los cuales haremos con las siguientes sentencias:

Primeramente creamos la rama auxiliar :

git flow hotfix start V1.1

Una vez creada la rama, agregamos las correcciones necesarias y las hacemos efectivas con commit. Después trasladamos los cambios a producción y a desarrollo con la siguiente sentencia:

git flow hotfix finish V1.1

Hasta aquí hemos hecho un ciclo del modelo de git flow enviando las modificaciones de las ramas auxiliares a las ramas principales.

Ventajas y desventajas de utilizar Git Flow.

Ventajas

  • Asegura claridad en el ciclo de vida de cada rama.
  • Las ramas siguen un patrón semántico.
  • Puedes desarrollar en paralelo.

Desventajas

  • Puede hacer que la historia se vuelva ilegible.
  • Algunas ramas se consideran redundantes.
  • Dificulta la entrega continua.

 

Generar una aplicación web con Maven.

¿Que voy a aprender?

En esta entrada te voy a mostrar como crear un cascaron para una aplicación Web monolítica en Java utilizando Maven.

En un post anterior te mostre como generar este mismo proyecto, pero con el IDE eclipse.

¿Que necesito tener instalado?

  1. Maven
  2. Java (No seremos exigentes con las versiones, pero preferiblemente de la 8 en adelante)
  3. Eclipse IDE para ver el resultado

Manos a la obra

Abrimos nuestra consola de preferenciate ubicas donde quieres que se genere el proyecto y ejecutas

mvn archetype:generate -DartifactId=webapp-sample -DgroupId=ni.org.jug -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

Brevemente te explico que hace este comando

  1. archetype:generate : le indica al maven que queremos generar un proyecto apartir de una plantilla
  2. -DartifactId: Es el nombre de nuestro proyecto, esto es personalizable puedes llamarlo como tu quieras..
  3. -DgroupId: Es la paqueteria base, generalmente dado por el dominio de nuestra organización, esto es personalizable.
  4. -DarchetypeArtifactId: El nombre de la plantilla web de la cual queremos generar nuestro proyecto.
  5. -DinteractiveMode: Le indicamos que al generar nuestro proyecto no nos haga mas preguntas :D.

Una vez terminada la ejecución obtendremos el siguiente resultado:

Proyecto Generado.

Proyecto Generado.

Importar el proyecto a Eclipse

Una vez finalizado, vamos a importar el proyecto generado a nuestro eclipse IDE.

  1. Seleccionamos la opción File -> Import

import

Opción Import

2. Buscar la opción maven y seleccionar la opción Existing Maven Projects

Opción Maven

Opción Maven

3. Buscamos el directorio donde se encuentra el proyecto que generamos previamente, puedes utilizar el button Browse…

selección del proyecto

Selección del Proyecto

Resultado Final:

El resultado final es un proyecto web con una estructura generado a partir de una plantilla, ya con esto hemos hecho el primer paso para poder desarrollar un sistema web monolítico con Java

Proyecto Importado

Proyecto Importado

 

Nosotros y terceros seleccionados utilizamos cookies o tecnologías similares con fines técnicos y, con su consentimiento, para otras finalidades (“interacciones y funcionalidades básicas”, “mejora de la experiencia”, “medición” y “segmentación y publicidad”) según se especifica en la política de cookies. Usted es libre de otorgar, denegar o revocar su consentimiento en cualquier momento.    Configurar y más información
Privacidad