Cómo particionar un proyecto JSF para desarrolladores frente a codificadores de UI, cuando se usa Git como el repository de código

Estoy migrando mi aplicación JSF a Cloudbees, básicamente una plataforma Maven / Jenkins / Git. Lamentablemente, no tengo mucha experiencia con Maven / Jenkins / Git.

Quiero crear una forma sencilla en que los desarrolladores de UI puedan sincronizarse con el xhtml y los files de UI relacionados, sin necesidad del código de Java en sus máquinas. Los desarrolladores de Java necesitarían tanto el código de UI como el código de Java. En ambos casos, cuando empujan su contenido, debe ser integrable con el process de compilation continua de Jenkins.

¿Existe un buen patrón o sugerencia que podría hacer para dividir el proyecto, de modo que los desarrolladores de UI tengan su XHTML y otros files (imágenes, CSS, etc.), mientras que los desarrolladores de Java lo tienen todo? Esto necesitaría trabajar con Maven, Git y Jenkins. Gracias por toda la ayuda.

Una última cosa: los desarrolladores de Java usarán Eclipse. Los desarrolladores de UI no necesitan usar Eclipse, por lo que el enlace será Git.

Esto es realmente solo una pregunta de Maven / JSF. Jenkins realmente no entra en la ecuación, y tampoco lo hace CloudBees (nótese que [cloudbees] también soportan repositorys alojados de Subversion que pueden o no ajustarse mejor a su estructura de proyecto … en cualquier caso, GIT es "mejor" en mi humilde opinión, así que iría por GIT sobre Subversion si fuera yo)

Tienes tres opciones realmente.

  1. Mantenga el XHTML en un repository separado de GIT

  2. Mantenga todo en un repository.

  3. Una especie de mezcla de 1 y 2

Opción 1

Esto te llevará por el path de los submodules de GIT … ese es el único caso en el que preferiría Subversion a GIT … y no, no me refiero a que svn:externals sea ​​mejor que GIT, más de lo que Subversion te permite Echa un vistazo a una parte del repository, para que el equipo de IU simplemente pueda verificar la ruta secundaria donde viven los files XHTML, IOW

 $ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk/web-module/src/main/webapp web-content $ cd web-content 

funcionaría para el equipo de UI y

 $ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk jsf-app $ cd jsf-app $ mvn package 

funcionará para los desarrolladores de Java.

Para lograr lo mismo con GIT, se requiere el uso de submodules, por lo que tendría un submodule en web-module/src/main/webapp en el repository GIT de jsf-app.

Donde esto se convierte en un dolor es cuando los desarrolladores de Java necesitan hacer ajustes a los files XHTML también, dependiendo del IDE puede ser complicado lograr que las confirmaciones en el submodule se tomen correctamente. Además, ahora no tiene una única revisión para seguir, los dos repos pueden moverse de forma independiente … lo que puede degradar algunas de las características de GIT.

Cuando desee utilizar el complemento de lanzamiento Maven (y debería querer hacerlo), los submodules lo evitarán, ya que la idea de labelr submodules actualmente no es compatible con el complemento de lanzamiento, y hay dos reposes separados para rastrear el problema nuevamente.

opcion 2

Esta es realmente la mejor opción … a pesar de que está haciendo exactamente lo que dijiste que no querías hacer.

El truco aquí es hacer que la vida del desarrollador de UI sea más fácil.

Debe configurar un buen perfil de Maven con un objective pnetworkingeterminado que termine ejecutando la aplicación web, por ejemplo, embarcadero: ejecutar, ver, por ejemplo, este perfil de pom si echa un vistazo a ese proyecto y simplemente ejecuta

 $ mvn -Pdemo 

Arrancará la aplicación web desde el submodule habiendo construido todos los modules dependientes.

El uso de este enfoque significa que los usuarios de UI también pueden probar los cambios de UI integrados en la aplicación JSF, lo que networkinguce la carga en los chicos de Java.

Opción 3

Este es un tipo de combinación, tienes modules GIT separados para el XHTML y el Java, pero son proyectos válidos de Maven.

Puedes lograr esto de dos maneras …

  • Haga que el module XHTML sea un <packaging>war</packaging> que se extraiga en la aplicación web Java utilizando Maven War Overlays

  • Haga que el module XHTML sea un <packaging>war</packaging> que tenga las dependencies Java directamente.

El primero tiene la ventaja de que los desarrolladores de Java pueden trabajar con el código de Java rápidamente, pero el efecto secundario es la fijación de XHTML es complicado, por ejemplo, attributes de data binding

El segundo hace que el ajuste de Java sea más difícil (tienen que seguir ejecutando mvn install ), los mvn install UI deben bajar los Java .JAR del repository remoto de Maven si quieren girar el package de Maven, y por lo tanto, pueden exponer algunos de sus java interna a los chicos de UI.

TL; DR

Personalmente, a less que mantener las cosas en secreto de los chicos de la interfaz de usuario es algo que es importante, elegiría la opción 2