Wiki de EGC - Contribuciones del usuario [es]

Despliegue (Heroku)

2018-12-11T08:03:16Z

Resinas:

En esta práctica vamos a adaptar nuestra app a un entorno de desarrollo basado en Heroku.

Heroku
--------------

Heroku es una empresa que ofrece "Plataformas como servicios" y nos permite despreocuparnos de tareas de mantenimiento de infraestructura (por ejemplo aprovisionamiento y administración de servidores) de las soluciones que ofrecen "Infraestructura como Servicio" (Amazon EC2).

Heroku CLI
-----------------
La comunicación con heroku se realiza principalmente desde la terminal o desde la web, para ello ofrecen clientes de terminal para los sistemas operativos más usados. Asimismo, delega en un sistema de recetas el despliegue de las aplicaciones que deseemos.

Para crear nuevas aplicaciones en heroku usaremos:
<source lang="bash">
heroku create "app name"
</source>

Añadiendo un nuevo remote para nuestra app:
<source lang="bash">
heroku git:remote -a "app name"
</source>

Heroku Procfile
------------------
Las aplicaciones Heroku incluyen un archivo Procfile en su raiz, al estilo de lo que hacíamos en la práctica anterior. Este archivo de recetas se ejecuta por una app en el arranque de la misma. En el Procfile se puede describir entre otros:

* El servidor web de tu aplicación
* Distintos procesos de "workers"
* Un proceso singleton (e.g. relog, semaforos, ...)
* Tareas a ejecutar antes de lanzar el despliegue.

Entonces, podremos resumir que los pasos para hacer release de decide en el procfile a crear:
<source lang="bash">
% prepara el repositorio para su despliegue.
release: sh -c 'cd decide && python manage.py migrate'
% especifica el comando para lanzar Decide
web: sh -c 'cd decide && gunicorn decide.wsgi --log-file -'

Enviando el código a Heroku
------------------
Una vez tenemos una rama remota asociada a heroku, podemos hacer push a esta rama para que se considere una release

<source lang="bash">
git push heroku master
</source>

Observemos los errores y veamos como resolverlos.

1) Parametros por defecto:

decide/decide/settings.py
<source lang="python">
BASEURL = 'https://TU URL'
...
APIS = {}
...
import django_heroku
django_heroku.settings(locals())
</source>

2) Dependencias
Los cambios en estas dependencias son django-heroku para evitar problemas con el comando collectstatic de django y gunicorn como servidor
requirements.txt

<source lang="bash">
django-heroku
gunicorn
</source>

3) Finalmente, tenemos que fijar la versión de python a usar. Esto se define en el archivo runtime.txt

<source lang="bash">
python-3.7.1
</source>

El último paso es conectarnos a heroku y crear un super usuario para las votaciones
<source lang="bash">
heroku run -a YOUR APP NAME "sh -c 'cd decide && python manage.py createsuperuser'"
</source>

Referencias
---------------
* [https://devcenter.heroku.com/articles/getting-started-with-python Getting started de Python en Heroku]

Integración continua

2018-11-19T15:45:11Z

Resinas:

* [[Primeros pasos con Travis CI]]
* [[Flujo de trabajo con GitHub]]
* [[Notificaciones]]
* [[Uso con bases de datos]]
* [[Jobs con múltiples builds]]
* [[Despliegue]]

Integración continua (con Python)

2018-11-19T15:44:54Z

Resinas:

* [[Travis CI para integración continua]]
* [[Flujo de trabajo con GitHub]]
* [[Notificaciones]]
* [[Jobs con múltiples builds para Decide]]

También puedes consultar los ejemplos con Java en [[Integración continua]]

2017-12-09T01:47:21Z

Resinas:

Una de las ventajas que ofrecen los sistemas de integración continua es que permiten automatizar la prueba del código en distintos entornos o con distintos servicios (por ejemplo, distintas bases de datos), algo que resultaría muy tedioso en caso de hacerlo cada desarrollador individualmente.

En Travis CI, esto se puede realizar a través de la llamada ''build matrix'', que es una combinación de posibles configuraciones del entorno de ejecución de la build. Por ejemplo, para el lenguaje Java, la build matrix que se puede especificar incluye la versión de JDK que se utilizará y las variables de entorno que se definen en la construcción.

= Ejercicio =
# Utilizando la documentación de https://docs.travis-ci.com/user/languages/java/ configura el <code>.travis.yml</code> para que construya el proyecto en Oracle JDK 7, Open JDK 7 y Oracle JDK 8
# Añade ahora para que construya el proyecto probándolo con dos bases de datos distintas: MySQL y PostgreSQL (los datos del driver de PostgreSQL para la configuración se pueden encontrar en: https://jdbc.postgresql.org/documentation/head/load.html). No te olvides de añadir el driver de PostgreSQL al pom.xml (http://search.maven.org/#artifactdetails%7Corg.postgresql%7Cpostgresql%7C42.1.4.jre7%7Cbundle).
# ¿Cuántos jobs se están lanzando ahora por cada build?

Uso con bases de datos

2017-12-09T01:40:34Z

Resinas: Página creada con «Es frecuente que una aplicación requiera de bases de datos u otros servicios externos para poder probarse. Travis CI tiene soporte de serie para las bases de datos más ha...»

Es frecuente que una aplicación requiera de bases de datos u otros servicios externos para poder probarse. Travis CI tiene soporte de serie para las bases de datos más habituales como MySQL, PostgreSQL, MongoDB o ElasticSearch. La lista completa se puede encontrar en https://docs.travis-ci.com/user/database-setup/ así como la forma de configurar cada una de ellas que, de nuevo, se realiza a través de <code>.travis.yml</code>. Por ejemplo, para configurar mysql hay que añadir a <code>.travis.yml</code> lo siguiente:

<source lang="yaml">
...
services:
- mysql

before_install:
- mysql -e 'CREATE DATABASE IF NOT EXISTS hello_test;'
</source>

La primera instrucción le dice a Travis CI que instale mysql pues lo vamos a utilizar y la segunda instrucción le indica que cree la base de datos justo antes de la fase de instalación. Travis ya crea dos usuarios por defecto: travis y root, ambos con password vacío. El resto de bases de datos se configuran de una forma bastante similar.

No obstante, la configuración de la base de datos es sólo la mitad del recorrido. Una vez configurada, es necesario indicar a nuestra aplicación cuál es la base de datos que vamos a utilizar. Una de las formas más habituales de hacer esto hoy en día es por medio de variables de entorno. Además de para indicar la base de datos a utilizar, las variables de entorno también se suelen usar con frecuencia para almacenar las credenciales de acceso a servicios externos como Amazon S3 o Facebook. Lógicamente para poder hacer esto, nuestra aplicación tiene que estar preparado para leer las variables de configuración del entorno. Además, es necesario configurar esas variables de entorno en Travis CI. Eso se puede hacer de dos formas (ver más detalles en https://docs.travis-ci.com/user/environment-variables/):
* A través de la configuración del repositorio en la web de Travis CI
* A través del fichero <code>.travis.yml</code>

Si elegimos esta segunda opción, las variables de entorno se definen añadiendo a <code>.travis.yml</code> lo siguiente:
<source lang="yaml">
...
env:
- DATABASE=jdbc:mysql://localhost:3306/hello_test DB_USERNAME=travis DB_PASSWORD=""
</source>

Esta configuración define cuatro variables de entorno: DATABASE, DB_USERNAME y DB_PASSWORD, que son las necesarias para definir la configuración de bases de datos en una aplicación Java que utilice Spring Data. En este caso, está configurando el acceso a una base de datos MySQL llamada hello_test que está en localhost y a la que accede por medio del usuario travis con contraseña vacía.

= Ejercicio =

# Cámbiate a la rama add-databases del repositorio hello-java. En esta rama, se modifica el código para que el saludo, en lugar de estar definido a mano en un fichero de código, esté almacenado en una base de datos. Para eso, se usa Spring JPA y las variables de entorno que se necesitan son:
#* SPRING_DATASOURCE_DRIVERCLASSNAME, que debe tomar el valor com.mysql.jdbc.Driver para una base de datos MySQL
#* SPRING_DATASOURCE_URL, que debe tomar el valor jdbc:mysql://localhost:3306/nombredelabasededatos
#* SPRING_DATASOURCE_USERNAME, que es el nombre del usuario de acceso a la base de datos
#* SPRING_DATASOURCE_PASSWORD, que es la contraseña de ese usuario
# Añade un fichero <code>.travis.yml</code> que construya la aplicación utilizando para las pruebas una base de datos MySQL.

Primeros pasos con Travis CI

2017-12-09T00:24:43Z

Resinas: /* Para empezar con Travis CI */

Integración continua con Travis CI

2017-12-08T15:20:16Z

Resinas:

* [[Primeros pasos con Travis CI]]
* [[Flujo de trabajo con GitHub]]
* [[Notificaciones]]
* [[Uso con bases de datos]]
* [[Jobs con múltiples builds]]

Jobs con múltiples builds

2017-12-08T15:19:17Z

Notificaciones

2017-12-08T09:35:24Z

Resinas:

Por defecto, Travis CI envía notificaciones de correo electrónico al autor del commit cuando es miembro del repositorio, esto es cuando tienen:
* permisos de push o administración en repositorios públicos
* permisos de pull, push o administración en repositorios privados

Los correos se envían cuando, en una rama dada:
* un build se ha ejecutado y ha fallado
* se acaba de corregir un build que había fallado previamente

No obstante, es posible mostrar información de la construcción y configurar más detalles acerca de las notificaciones. A continuación se describe dos formas de llevarlo a cabo:

= Mostrando imágenes con el estado de la construcción =
Es posible mostrar información de la construcción en una página web o en el README.md de los repositorios de GitHub. Para hacerlo, tan sólo hay que seguir las instrucciones que aparece aquí: https://docs.travis-ci.com/user/status-images/, seleccionando en el desplegable la opción "Markdown" y copiando el texto que aparece en el fichero README.md del repositorio.

'''Ejercicio:''' Configura el README.md de tu proyecto para que muestre una imagen con el estado de la construcción.

= Configurando notificaciones =
Travis CI te permite configurar el comportamiento por defecto de envíos de correos así como habilitar notificaciones a otros servicios como Slack, Pushover o IRC. La configuración de las notificaciones se hace también a través del fichero <code>.travis.yml</code> aunque en algunos casos es necesario configurar previamente la integración con el servicio. La documentación sobre cómo configurar las notificaciones está en https://docs.travis-ci.com/user/notifications/

'''Ejercicio:''' Configura Travis CI para que envíe un correo siempre que haya una nueva build, tanto si tiene éxito como si falla, y que además notifique siempre a tu correo electrónico independientemente de quién haya hecho el commit.

Notificaciones

2017-12-07T18:40:20Z

Resinas: Página creada con «Por defecto, Travis CI envía notificaciones de correo electrónico al autor del commit cuando es miembro del repositorio, esto es cuando tienen: * permisos de push o admin...»

Flujo de trabajo con GitHub

2017-12-07T18:33:30Z

Resinas: Página creada con «Como ya hemos comentado en la asignatura, una forma muy habitual de trabajar con GitHub es por medio de [https://help.github.com/articles/about-pull-requests/ pull requests...»

Como ya hemos comentado en la asignatura, una forma muy habitual de trabajar con GitHub es por medio de [https://help.github.com/articles/about-pull-requests/ pull requests]. Las pull requests se crean desde una rama a otra del repositorio y permite decirle a otros qué cambios has hecho en un repositorio en GitHub. Una vez que un pull request se abre, puedes discutir y revisar los cambios potenciales con colaboradores y continuar haciendo commits antes de que los cambios se integren en el repositorio. Un escenario muy habitual donde se trabaja con pull requests es si se sigue un flujo de desarrollo del estilo de [https://guides.github.com/introduction/flow/ GitHub Flow].

Cuando se abre una pull request, Travis CI recibe una notificación de pull request de GitHub. Esta notificación se transforma en una nueva build. Durante la build se actualiza el estado de los commits a uno de los siguientes:
* un warning porque aún se está construyendo
* que la pull request se debe de integrar con cuidado porque la build falló
* que la pull request se puede integrar sin problemas porque la build tuvo éxito

Travis CI inicia una build cuando se abre por primera vez una pull request y cuando se añaden commits a ella. Además, la prueba se realiza a partir de un merge de la rama con la feature y la rama master, no únicamente de la rama con la feature.

= Ejercicio =

# Vamos a añadir una nueva característica a nuestra aplicación que permita decir hola en distintos idiomas. Para eso, vamos a crear una rama con nombre add-languages.
# En la nueva rama creada vamos a editar el fichero greeting.html en src/main/resources/templates con este contenido<source lang="html">
<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<title>Getting Started: Serving Web Content</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
<p th:text="${hello} + ', ' + ${name} + '!'" />
</body>
</html>
</source>
# añadimos la clase GreetingTranslator:<source lang="java">
package hello;

public class GreetingTranslator {

public String sayHelloIn(String lang) {
String hello;
if ("en".equals(lang)) {
hello = "hello";
} else if ("es".equals(lang)) {
hello = "hola";
} else {
hello = "no hablo tu idioma";
}
}

}
</source>
# y modificamos el método greeting de la clase GreetingController como sigue:<source lang="java">
@RequestMapping("/greeting")
public String greeting(@RequestParam(value="name", required=false, defaultValue="World") String name,
@RequestParam(value="lang", required=false, defaultValue="en") String lang,
Model model) {
model.addAttribute("hello", greetingTranslator.sayHelloIn(lang));
model.addAttribute("name", name);
return "greeting";
}
</source>
# Haz un commit de estos cambios y haz un push de la nueva rama a GitHub
# Una vez que hemos decidido que estos cambios abarcan la funcionalidad deseada, vamos a crear una pull request siguiendo estas instrucciones: https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request
# Si abres la pull request que se ha creado, podrás observar abajo cómo se ejecuta una nueva build en Travis CI con la pull request.

Introducción a Composer

2017-12-07T18:00:18Z

Resinas:

En PHP no existen herramientas tan asentadas y frecuentemente usadas para la gestión de la construcción de proyectos como en Java. No obstante, recientemente si que han aparecido varias de entre las que cabe destacar a [https://getcomposer.org Composer] por su uso extendido. A diferencia de Maven, Composer se encarga exclusivamente de la gestión de dependencias por lo que no ofrece funcionalidades para la ejecución de las distintas tareas del proceso de construcción del proyecto.

La gestión de dependencias que realiza Composer es muy similar a la de Maven y, sobre todo, a la de [http://npmjs.com/ NPM], que es un sistema de gestión de dependencias en Javascript.

= Instalar Composer =

La instalación de Composer requiere tener instalado PHP y poder acceder a él desde línea de comandos. Si no lo tienes instalado, una opción es utilizar la imagen de PHP de Docker de la siguiente forma:

<source lang="bash">
% docker run -it -v "$PWD":/usr/src/myapp -w /usr/src/myapp php:7.0-cli /bin/bash
</source>

Eso crea un contenedor con PHP 7.0 e inicia una sesión en terminal. Además, mapea el directorio actual al directorio /usr/src/myapp del contenedor. Por último, antes de usar Composer tenemos que instalar git y zip/unzip pues Composer los utiliza para descargarse las dependencias. Eso se puede hacer de la siguiente forma:

<source lang="bash">
root@e20f7160c57c:/usr/src/example# apt-get update
Get:1 http://security.debian.org jessie/updates InRelease [63.1 kB]
Ign http://deb.debian.org jessie InRelease
Get:2 http://deb.debian.org jessie-updates InRelease [145 kB]
Get:3 http://security.debian.org jessie/updates/main amd64 Packages [588 kB]
Get:4 http://deb.debian.org jessie Release.gpg [2373 B]
Get:5 http://deb.debian.org jessie Release [148 kB]
Get:6 http://deb.debian.org jessie-updates/main amd64 Packages [23.2 kB]
Get:7 http://deb.debian.org jessie/main amd64 Packages [9063 kB]
Fetched 10.0 MB in 5s (1865 kB/s)
Reading package lists... Done

root@e20f7160c57c:/usr/src/example# apt-get install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
git-man less libcurl3-gnutls liberror-perl libexpat1 libpopt0 libx11-6 libx11-data libxau6 libxcb1 libxdmcp6
libxext6 libxmuu1 openssh-client rsync xauth
Suggested packages:
gettext-base git-daemon-run git-daemon-sysvinit git-doc git-el git-email git-gui gitk gitweb git-arch git-cvs
git-mediawiki git-svn ssh-askpass libpam-ssh keychain monkeysphere openssh-server
Recommended packages:
ssh-client
The following NEW packages will be installed:
git git-man less libcurl3-gnutls liberror-perl libexpat1 libpopt0 libx11-6 libx11-data libxau6 libxcb1
libxdmcp6 libxext6 libxmuu1 openssh-client rsync xauth
0 upgraded, 17 newly installed, 0 to remove and 1 not upgraded.
Need to get 7629 kB of archives.
After this operation, 33.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
...

root@e20f7160c57c:/usr/src/example# apt-get install zip
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
unzip
The following NEW packages will be installed:
unzip zip
0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 390 kB of archives.
After this operation, 1002 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
...
</source>

Una vez tenemos nuestro contenedor listo, ya podemos instalar Composer siguiendo las [https://getcomposer.org/doc/00-intro.md instrucciones de su web]:

<source lang="bash">
root@e20f7160c57c:/usr/src# php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
root@e20f7160c57c:/usr/src# php -r "if (hash_file('SHA384', 'composer-setup.php') === '544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
Installer verified
root@e20f7160c57c:/usr/src# php composer-setup.php
All settings correct for using Composer
Downloading...

Composer (version 1.5.5) successfully installed to: /usr/src/composer.phar
Use it: php composer.phar

root@e20f7160c57c:/usr/src# php -r "unlink('composer-setup.php');"
root@e20f7160c57c:/usr/src# mv composer.phar /usr/local/bin/composer
</source>

De forma alternativa, se puede crear un Dockerfile con estos comandos:
<source>
FROM php:7.0-cli
RUN apt-get update && apt-get install -y git unzip zip --no-install-recommends && rm -r /var/lib/apt/lists/*
RUN mkdir -p /usr/src; \
cd /usr/src; \
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"; \
php -r "if (hash_file('SHA384', 'composer-setup.php') === '544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"; \
php composer-setup.php; \
php -r "unlink('composer-setup.php');"; \
mv /usr/src/composer.phar /usr/local/bin/composer; \
cd /
</source>

Crear una nueva imagen a partir de ese Dockerfile:

<source lang="bash">
% docker build -t php:7.0-composer .
</source>

Y crear un contenedor con la nueva imagen:

<source lang="bash">
% docker run -it -v "$PWD":/usr/src/myapp -w /usr/src/myapp php:7.0-composer /bin/bash
</source>

= Uso básico de Composer =

Para ilustrar el funcionamiento de Composer vamos a añadir un par de dependencias a un proyecto en PHP. El equivalente en Composer al pom.xml de Maven es el fichero composer.json. Lo que ocurre es que, a diferencia de lo que ocurre en Maven, el fichero se puede editar directamente o podemos dejar que Composer lo vaya modificando de forma automática a partir de los comandos que vamos ejecutando en línea de comandos.

El fichero composer.json describe las dependencias del proyecto y puede tener también otros datos adicionales como el nombre o versión del proyecto. El elemento básico que se especifica en un composer.json es el elemento require. Simplemente sirve para decir los paquetes de los que depende el proyecto:

<source lang="json">
{
"require": {
"monolog/monolog": "1.0.*"
}
}
</source>

En este composer.json se está indicando que el proyecto depende de un paquete llamado monolog del desarrollador monolog y fija la versión a la 1.0.* (es decir, cualquiera que tenga 1.0).

Una vez que tenemos un composer.json creado en nuestro proyecto, podemos descargarnos todas sus dependencias mediante:

<source lang="bash">
% composer install
</source>

El proceso es similar al de Maven y, al igual que Maven, existe un repositorio central donde se buscan por defecto los paquetes. Este repositorio se llama [https://packagist.org/ Packagist]. Puedes encontrar más información sobre él en la [https://getcomposer.org/doc/01-basic-usage.md#packagist documentación de Composer].

Si se quiere actualizar las dependencias a las últimas versiones se puede hacer:

<source lang="bash">
% composer update
</source>

= Scopes en las dependencias =

Al igual que ocurre en Maven, es posible indicar varios ''scopes'' para las dependencias de un proyecto, aunque en Composer sólo hay dos scopes: normal, que significa que la dependencia se usa tanto en desarrollo como en ejecución y ''development'', que significa que la dependencia se usa durante el desarrollo, por ejemplo, para ejecutar pruebas unitarias. La forma de indicarlo es que el elemento donde se indican las dependencias de desarrollo se llama <code>require-dev</code>:

<source lang="json">
{
"require-dev": {
"phpunit/phpunit": "^6.5"
}
}
</source>

= Composer por línea de comandos =

El composer.json lo podemos editar nosotros directamente, igual que se hace en maven con el pom.xml, o podemos añadir o eliminar dependencias haciendo uso de la interfaz de línea de comandos de Composer. Para añadir dependencias se hace por medio de:

<source lang="bash">
% composer require monolog/monolog
% composer require --dev phpunit/phpunit
</source>

Las dependencias se pueden eliminar utilizando:

<source lang="bash">
% composer remove phpunit/phpunit
</source>

= Ejercicio =

# Instala Composer
# Crea un fichero composer.json con las siguientes dependencias:
#* Última versión del paquete psr/log
#* Versión igual o superior a la 1.2.0 del driver de mongodb
#* Versión superior a la 1.1.0 del SDK de Dropbox para PHP
#* Versión igual o superior a la 6 del framework de pruebas unitarias phpunit para desarrollo
# Descarga las dependencias en tu ordenador.

= ¿Vas rápido? =
Echa un vistazo a https://getcomposer.org/doc/02-libraries.md y sigue el tutorial para hacer público un proyecto de hola mundo en PHP.

Integración continua con Travis CI

2017-12-07T16:12:39Z

Resinas: Página creada con «* Primeros pasos con Travis CI * Flujo de trabajo con GitHub * Jobs con múltiples builds * Notificaciones * Uso con bases de datos»

* [[Primeros pasos con Travis CI]]
* [[Flujo de trabajo con GitHub]]
* [[Jobs con múltiples builds]]
* [[Notificaciones]]
* [[Uso con bases de datos]]

Primeros pasos con Travis CI

2017-12-07T16:09:17Z

2017-11-24T12:30:23Z

Resinas: /* Cree el .jar y ejecute */

La configuración de plugins en Maven se realiza siempre a través del fichero pom.xml. En general, la configuración de plugins me va a servir para dos cosas:
* Adaptar el funcionamiento de un plugin a la forma que me interese en el proyecto.
* Vincular objetivos de un plugin a fases del ciclo de vida de maven.

A continuación vamos a ver tres ejemplos de cosas que se pueden conseguir por medio de la configuración de plugins.

=Seleccionar la versión de Java para compilación y ejecución con maven-compiler-plugin=
Por defecto, el plugin de compilación de maven fija tanto la versión del código (source) como la versión del .class generado (target) con la versión 1.5 de Java. Si queremos cambiarlo, es necesario configurar el plugin que se encarga de compilar el código (maven-compiler-plugin).

==Añadir el siguiente código al método main de la clase App==

<source lang="java">
import java.util.Arrays;
import java.util.List;
[...]
List<String> myList =
Arrays.asList("a1", "a2", "b1", "c2", "c1");

myList
.stream()
.filter(s -> s.startsWith("c"))
.map(String::toUpperCase)
.sorted()
.forEach(System.out::println);
</source>

Este código utiliza la funcionalidad de Streams de Java 1.8.

==Compilar el código modificado==
Observar el mensaje de error. ¿Por qué falla?

==Configurar pom.xml para que maven-compiler-plugin use la versión 1.8 de java==
<source lang="xml">
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.8< /source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
</source>

==Compilar de nuevo el código ==
Observar como ahora funciona ya correctamente. Si da errores, comprueba que la versión de JDK que tienes instalada es la 1.8.

=Modificar el manifest con maven-jar-plugin=
El manifest es un fichero que se puede incluir en los JAR y que indica cuál es el punto de entrada del mismo. Este fichero permite que se pueda ejecutar el JAR directamente con <code>java -jar fichero.jar</code> en lugar de tener que indicar la clase donde está el método main. Esto se puede conseguir configurando de forma adecuada el [https://maven.apache.org/plugins/maven-jar-plugin/ maven-jar-plugin] para establecer el punto de entrada del mismo.

==Moficar el pom.xml==
Añadir lo siguiente:
<source lang="xml">
…
<build>
<plugins>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>
<configuration>

<archive>
<manifest>

<mainClass>${project.groupId}.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
…

</source>
Esto configura el plugin ''jar'' para que defina el entry point del fichero JAR generado. Esta configuración se aplicará tanto al ejecutar el objetivo "jar:jar" como al ejecutar la fase "package" (a la que está vinculada por defecto el objetivo "jar:jar").

==Cree el .jar==
<source lang=bash>
mvn clean package
</source>
ó
<source lang=bash>
mvn clean jar:jar
</source>

¿Qué diferencias hay? ¿Es correcta esta segunda invocación? ¿Por qué?

==Ejecute el .jar generado==
<source lang=bash>
java -jar target\proy1-1.0-SNAPSHOT.jar
</source>

Ups. ¿Por qué falla?

=Copiar las dependencias con maven-dependency-plugin=
Se establecerá una carpeta dentro de target donde estarán todos los jars dependientes usando el [https://maven.apache.org/plugins/maven-dependency-plugin/ maven-dependency-plugin].

==Edite el pom.xml==
Añada el siguiente código

<source lang="xml">
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/dependencies</outputDirectory>
<includeScope> runtime </includeScope>
</configuration>
</execution>
</executions>
</plugin>
...
</source>

Se ha configurado el plugin ''dependency''. El objetivo ''copy-dependencies'' se ha asociado a la fase ''package'' y se ha configurado para que las dependencias de runtime se copien en la carpeta ''dependencies''.

==Cree el .jar y ejecute==
<source lang="bash">
mvn package
java -jar target/proy1-1.0-SNAPSHOT.jar
</source>

¿Sigue fallando?

==Hay que terminar de configurar el plugin Jar==
Hay que añadir las referencias en el manifest. Añada las siguientes líneas de configuración del plugin ''Jar'' anterior.

<source lang="xml">
...
<addClasspath>true</addClasspath>
<classpathPrefix> dependencies/</classpathPrefix>
...
</source>

= ¿Vas rápido? -> Tarea adicional =

El plugin Jar se ha configurado para que, durante su ejecución dentro del ciclo de vida default, se comporte de cierta manera. Sin embargo, el plugin dependency, que no se ejecuta normalmente, se ha configurado para que sí se ejecute.

Haga, ahora, que se creen 2 jars, uno con la configuración que hemos indicado arriba y otro sin que tenga ninguna configuración por nuestra parte. Esto no es habitualmente recomendable ya que lo ideal es que cada proyecto tenga un único resultado, pero sirve a modo de ejemplo para probar las características de Maven.

''Indicación:'' Además de tocar el atributo <code>manifest</code> tendrá que tocar el <code>finalName</code> para que cada jar tenga un nombre diferente (cf. [https://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html Jar Parameters]).