2010-11-03 3 views
8

Tenemos el siguiente escenario con nuestro proyecto:Cómo extender/personalizar una guerra con otro proyecto

  • Una aplicación web núcleo empaquetado como un archivo guerra (llamarlo proyecto Core).
  • La necesidad de "personalizar" o "ampliar" la aplicación central por cliente (llámelo Proyecto cliente). Esto incluye principalmente nuevas definiciones de bean (estamos usando Spring), es decir. reemplazando implementaciones de servicio en core.war con implementaciones específicas del cliente.
  • queremos desarrollar los proyectos básicos y de los clientes de forma independiente
  • Cuando se desarrolla el proyecto del cliente, tenemos que ser capaces de correr/depurarlo en Eclipse (en Tomcat) con el proyecto Core como una dependencia
  • Cuando el proyecto del Cliente está construido, el archivo de guerra resultante "incluye" los proyectos centrales y de clientes. Así que este .war es la versión específica del cliente de la aplicación

Estoy buscando sugerencias sobre la mejor manera de hacerlo en términos de herramientas y configuración de proyectos.

Estamos usando Ant actualmente, pero nos gustaría evitar enterrarnos en más hormigas. ¿Alguien ha hecho esto con Maven?

He visto muchas publicaciones sobre cómo crear una aplicación web que depende de una aplicación Java, pero no hay nada en una aplicación web que dependa de otra aplicación web.

Gracias!

Respuesta

3

En Eclipse hay una forma de WTP "nativa" para hacer esto. Utiliza principalmente carpetas vinculadas y un pequeño truco en el archivo .settings/org.eclipse.wst.common.component. Puede leer el artículo al respecto en http://www.informit.com/articles/article.aspx?p=759232&seqNum=3 el capítulo llamado "División de un módulo web en múltiples proyectos". El problema con esto es que la carpeta vinculada debe ser relativa a algunos path variable se puede definir en la pestaña Ventana/Preferencias/General/Espacio de trabajo/Recursos vinculados. De lo contrario, la definición de la carpeta vinculada (se puede encontrar en el archivo .project en la raíz del proyecto) contendrá la ruta específica de la estación de trabajo. La variable de ruta prácticamente debería ser la raíz del espacio de trabajo. Esta solución funciona muy bien con WTP, implementa y todo lo demás funciona como debería.

La segunda solución es usar hormiga para ello. Olvídalo. Lo lamentarás profundamente.

La tercera solución es usar maven para ello. Puede olvidarse de la comodidad de la publicación WTP si no hace algunos trucos. Use superposiciones de guerra como otros sugirieron. Asegúrese de instalar los extras m2eclipse, m2eclipse. Recientemente se lanzó un complemento de extensión que puede ayudarlo. Descrito en this blog. No lo probé, pero se ve bien. De todos modos, Maven no tiene nada que ver con las carpetas vinculadas, por lo que creo que incluso la primera solución y esta superposición Maven pueden vivir juntas si es necesario.

En cuanto a las construcciones sin cabeza, puede usar HeadlessEclipse para la primera solución. Está muerto (por mí) ahora, pero aún funciona :). Si utilizas las funciones de superposición maven + eclipse, las versiones sin cabeza están cubiertas por maven.

12

Parece que Maven WAR overlay hace lo que quiere.

+0

+1 - Exactamente. Mi proyecto principal en el trabajo usa este enfoque. –

+0

Sin embargo, esto no funciona desde dentro de Eclipse. – HDave

+0

maximdim He estado tratando de usar superposiciones WAR pero con esto no puedo obtener implementaciones en caliente de modificaciones en el proyecto principal. Cuando modifico una clase o un archivo estático (.js, .css) en el proyecto principal, no se refleja en la aplicación implementada. Estoy usando netbeans. ¿Alguna idea sobre cómo hacer que esto funcione? Esto obstaculiza seriamente el desarrollo. – Hoffmann

0

Esto es un poco más complicado pero a un nivel alto lo hacemos de la siguiente manera. Tenemos la plataforma central ui dividida en varios módulos de guerra basados ​​en las características (login-ui, catalog-mgmt-ui, etc.). Cada uno de estos módulos principales es personalizable por el equipo de atención al cliente.

Fusionamos todos estos módulos durante el tiempo de compilación en 1 único módulo de guerra. Las reglas de fusión se basan en el complemento de ensamblaje de maven.

0

Suele comenzar desde el código fuente de Java. WAR s no incluyen el código fuente de Java, solo las clases compiladas en WEB-INF/classes o JAR s en WEB-INF/libs.

Lo que me gustaría hacer es usar Maven y empezar un nuevo proyecto de aplicación Web vacío marca con ella: http://maven.apache.org/guides/mini/guide-webapp.html

Una vez que tenga la nueva estructura de proyecto vacío, copiar el código fuente de Java a ella (src/main/java) y rellene el siguiente lista de dependencias en pom.xml.

Una vez que haya hecho todo esto, puede usar mvn clean package para crear un archivo estándar WAR que puede implementar en Tomcat.

0

Es posible que desee considerar el diseño de su aplicación principal con funciones conectables basadas en interfaces.

Por ejemplo decir que su aplicación núcleo tiene un concepto de un objeto User y necesita proporcionar apoyo a las tareas en función de usuario común.Crear una interfaz UserStore;

public interface UserStore 
{ 
    public User validateUser(String username, String password) throws InvalidUserException; 
    public User getUser(String username); 
    public void addUser(User user); 
    public void deleteUser(User user); 
    public void updateUser(User user); 
    public List<User> listUsers(); 
} 

Luego, puede codificar su aplicación núcleo (la lógica de inicio de sesión, el registro de la lógica, etc.) en contra de esta interfaz. Es posible que desee proporcionar una implementación predeterminada de esta interfaz en su aplicación principal, como un DatabaseUserStore que sería efectivamente un DAO.

Defina el UserStore como un bean de resorte e inyéctelo donde sea necesario;

<bean id="userStore" class="com.mycorp.auth.DatabaseUserStore"> 
    <constructor-arg ref="usersDataSource"/> 
</bean> 

Esto le permite personalizar o ampliar la aplicación principal en función de las necesidades específicas del cliente. Si un cliente desea integrar la aplicación principal con su servidor de Active Directory, escriba una clase LDAPUserStore que implemente su interfaz UserStore usando LDAP. Configúrelo como Spring Bean y empaquete la clase personalizada como un contenedor dependiente.

Lo que te queda es una aplicación central que todos usan, y un conjunto de extensiones específicas para el cliente que puedes ofrecer y vender por separado; diablos, incluso puede hacer que el cliente escriba sus propias extensiones.

Cuestiones relacionadas