anchor.diff:  
   === Introducción
   
  -En este post analizaremos los aspectos generales implicados en la implementación de la funcionalidad de gestión / mantenimiento de la entidad Trabajo. Podéis bajaros el código fuente de la release 1.1.0 del proyecto, que corresponde  a este Post y al siguiente en https://github.com/lametaweb/jdrone/releases/tag/1.1.0[esta dirección].
  +En este post analizaremos los aspectos generales implicados en la implementación de la funcionalidad de gestión / mantenimiento de la entidad Trabajo. Recordad que un dron está asignado a ninguno, uno o más trabajos, que un trabajo lo realiza un único dron, y que un trabajo tiene una ruta consistente en dos o más puntos de ruta. 
  +
  +Podéis bajaros el código fuente de la release 1.1.0 del proyecto, que corresponde a este Post y al siguiente, en https://github.com/lametaweb/jdrone/releases/tag/1.1.0[esta dirección]. Otra alternativa para traeros el código fuente a vuestra máquina es que hagáis un fork de la aplicación desde mi cuenta de GitHub a vuestra cuenta y a continuación creéis vuestro repo local Git. De esta manera tendréis vuestro propio proyecto en GitHub e incluso podréis enviar un Pull Request a mi cuenta con las modificaciones que consideréis oportunas.
   
   En general un mantenimiento se organiza en tres pantallas: 
   
  
positive.code: 
  Es importante señalar que no existe una solución única a la hora de implementar un caso de uso, ni para las páginas, ni para los backing beans. Como regla general intentaremos siempre conseguir un resultado que proporcione la mejor experiencia de usuario al tiempo que cumpla con todos los requisitos funcionales acordados con el cliente. Respecto de esto último el cliente podría por ejemplo solicitar que en la página de detalle existieran accesos a ventanas emergentes de asistencia: Ventana calculadora de distancias entre dos puntos, ángulos entre trayectorias, conversión de unidades, etc.
  
  En el desarrollo de un mantenimiento existirán por tanto tareas de desarrollo generales y comunes a cualquier entidad, y tareas especificas, localizadas sobre todo en la pantalla de detalle, que son las que van a plantearnos los mayores retos a la hora de conseguir la funcionalidad deseada.
  
  === Configuraciones adicionales sobre el entorno de trabajo
  
  Queremos que nuestra productividad sea máxima y para ello decidimos en este punto del proyecto instalar la librería de componentes Primefaces así como la última versión disponible de JSF.
  
  Añadir Primefaces al proyecto es sencillo, basta con añadir la dependencia correspondiente al proyecto:
  
  [source,xhtml,indent=0]
  ----
  
negative.code: 		</dependency>
  ----
  
  Sin embargo, actualizar JSF desde la versión 2.1 a la 2.2 no es tan simple. El procedimiento para añadir el nuevo módulo de servidor dista de ser directo. Se intentó seguir el procedimiento existente en internet sin resultados positivos: En resumen el proceso pasa por bajar de GitHub una aplicación Maven que genera un fichero CLI que realiza el deploy de los tres slots correspondientes a los tres módulos que se ven afectados por la actualización. Sin embargo uno de los slots da problemas ya que el script está actualizado para operar con las versiones iniciales del servidor Wildfly y no con JBoss EAP.
  
  A la vista de lo anterior aprovecharemos esta dificultad y la convertiremos en ventaja: Optamos por instalar el nuevo servidor Wildfly en su última versión disponible, en estos momentos la 9.0.1, y así tener a nuestra disposición una plataforma Java EE 7 completa. Bien, lo primero es descargar el fichero de instalación del servidor desde http://wildfly.org/downloads/[esta página]. Tenéis que elegir la primera de las opciones en la lista, etiquetada con _Java EE7 Full & Web Distribution_.
  
  NOTE: En el momento de revisar este Post ya estaba disponible la versión 10 de Wilfly, así que instaladla si queréis en vez de la versión 9 para tener las últimas correcciones de bugs y últimas versiones de las librerías. Entiendo que no debe afectar en cuanto a instalación e integración con Eclipse. Descargaos también los _Quickstarts_ porque os van a venir muy bien como material de consulta en las etapas iniciales de la implementanción de un nuevo proyecto sea cual sea su naturaleza.
  
  Tras la instalación del nuevo servidor, antes de iniciarlo, debemos añadir un usuario. Para ello ejecutad el archivo por lotes _bin\add-user.bat_ y seguid las indicaciones.
  
  Lo siguiente es añadir WildFly a Eclipse como nueva unidad de ejecución. La versión de las JBoss Tools sólo ofrecía en ese momento un conector para la versión 8 pero después de las pruebas de arranque y parada se comprueba no hay problemas en usarlo para la versión 9.
  
  Por último tendremos que realizar los cambios necesarios en nuestro proyecto para adaptarlo al cambio de servidor. En primer lugar tendremos que actualizar las dependencias Maven a las del nuevo servidor, un proceso sin demasiada complicación. Podéis consultar el contenido del fichero _pom.xml_ en el código fuente del proyecto.
  
  Se ha refactorizado además el ciclo de construcción de modo que ahora existe un profile _despliegue-recursos_ que se debe ejecutar la primera vez que despleguemos la aplicación, o bien cuando los recursos hayan sido eliminados del mismo por cualquier motivo. Tenéis también que crear un nueva configuración de ejecución: Botón derecho sobre proyecto y _Run As_ > _Run Configurations..._  Botón derecho sobre _Maven build_ > _New_.  En la entrada _Goals_ escribid `clean install -Pdespliegue-recursos` y dad un nombre al nuevo perfil.
  
  