Maven2: Mejores prácticas para proyectos empresariales (archivo EAR)

100

Estoy cambiando de Ant a Maven y estoy tratando de descubrir la mejor práctica para configurar un proyecto empresarial basado en archivos EAR.

Digamos que quiero crear un proyecto bastante estándar con un archivo jar para los EJB, un archivo WAR para el nivel web y el archivo EAR encapsulado, con los descriptores de implementación correspondientes.

¿Cómo lo haría? ¿Crear el proyecto archetypeArtifactId=maven-archetype-webappcomo con un archivo war y extenderlo desde allí? ¿Cuál es la mejor estructura de proyecto (y ejemplo de archivo POM) para esto? ¿Dónde se colocan los descriptores de implementación relacionados con el archivo ear, etc.?

Gracias por cualquier ayuda.

Maik
fuente

Respuestas:

96

Creas un nuevo proyecto. El nuevo proyecto es su proyecto de ensamblaje EAR que contiene sus dos dependencias para su proyecto EJB y su proyecto WAR.

Así que en realidad tienes tres proyectos maven aquí. Un EJB. Una GUERRA. Una oreja que une las dos partes y crea la oreja.

Maven puede generar descriptores de implementación o colocarlos dentro del directorio de recursos en la estructura del proyecto EAR.

El maven-ear-plugin es lo que usa para configurarlo, y la documentación es buena, pero no del todo clara si todavía está averiguando cómo funciona maven en general.

Entonces, como ejemplo, podría hacer algo como esto:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany</groupId>
  <artifactId>myEar</artifactId>
  <packaging>ear</packaging>
  <name>My EAR</name>

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-ear-plugin</artifactId>
        <configuration>
          <version>1.4</version>
          <modules>
            <webModule>
              <groupId>com.mycompany</groupId>
              <artifactId>myWar</artifactId>
              <bundleFileName>myWarNameInTheEar.war</bundleFileName>
              <contextRoot>/myWarConext</contextRoot>
            </webModule>
            <ejbModule>
              <groupId>com.mycompany</groupId>
              <artifactId>myEjb</artifactId>
              <bundleFileName>myEjbNameInTheEar.jar</bundleFileName>
            </ejbModule>
          </modules>
          <displayName>My Ear Name displayed in the App Server</displayName>
          <!-- If I want maven to generate the application.xml, set this to true -->
          <generateApplicationXml>true</generateApplicationXml>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.3</version>
        <configuration>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
    </plugins>
    <finalName>myEarName</finalName>
  </build>

  <!-- Define the versions of your ear components here -->
  <dependencies>
    <dependency>
      <groupId>com.mycompany</groupId>
      <artifactId>myWar</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>war</type>
    </dependency>
    <dependency>
      <groupId>com.mycompany</groupId>
      <artifactId>myEjb</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>ejb</type>
    </dependency>
  </dependencies>
</project>
Mike Cornell
fuente
98
Encontré mi propia respuesta un año después cuando tuve la misma pregunta. ¡Buen trabajo yo!
Mike Cornell
1
Para mí, esto funcionó cuando lo configuré typecomoejb <type>ejb</type>
gammay
Ese pom arroja algunas advertencias: 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-ear-plugin is missingy 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing, por lo que es posible que desee actualizar su excelente respuesta
DiegoAlfonso
46

Lo que me ayudó mucho fue ejecutar el arquetipo de Maven: generar objetivo y seleccionar uno de los arquetipos, algunos de los cuales parecen actualizarse regularmente (en particular, JBoss parece estar bien mantenido).

mvn archetype:generate

Cientos de arquetipos aparecieron en una lista numerada de la cual seleccionar (¡519 a partir de ahora!). El objetivo, aún en ejecución, me pidió que hiciera una selección ingresando un número o ingresando una cadena de búsqueda, por ejemplo:

513: remote -> org.xwiki.commons:xwiki-commons-component-archetype
514: remote -> org.xwiki.rendering:xwiki-rendering-archetype-macro
515: remote -> org.zkoss:zk-archetype-component
516: remote -> org.zkoss:zk-archetype-webapp
517: remote -> ru.circumflex:circumflex-archetype (-)
518: remote -> se.vgregion.javg.maven.archetypes:javg-minimal-archetype (-)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains):

Ingresé la cadena de búsqueda "oreja", que redujo la lista a solo 8 elementos (a partir de hoy):

Choose archetype:
1: remote -> org.codehaus.mojo.archetypes:ear-j2ee14 (-)
2: remote -> org.codehaus.mojo.archetypes:ear-javaee6 (-)
3: remote -> org.codehaus.mojo.archetypes:ear-jee5 (-)
4: remote -> org.hibernate:hibernate-search-quickstart (-)
5: remote -> org.jboss.spec.archetypes:jboss-javaee6-ear-webapp 
6: remote -> org.jboss.spec.archetypes:jboss-javaee6-webapp-ear-archetype
7: remote -> org.jboss.spec.archetypes:jboss-javaee6-webapp-ear-archetype-blank
8: remote -> org.ow2.weblab.tools.maven:weblab-archetype-searcher

Seleccioné "org.jboss.spec.archetypes: jboss-javaee6-ear-webapp" (ingresando la selección "5" en este ejemplo).

A continuación, el objetivo me pidió que ingresara el groupId, artifactId, los nombres de los paquetes, etc., y luego generó la siguiente aplicación de ejemplo bien documentada:

[pgarner@localhost Foo]$ tree
.
|-- Foo-ear
|   `-- pom.xml
|-- Foo-ejb
|   |-- pom.xml
|   `-- src
|       |-- main
|       |   |-- java
|       |   |   `-- com
|       |   |       `-- foo
|       |   |           |-- controller
|       |   |           |   `-- MemberRegistration.java
|       |   |           |-- data
|       |   |           |   `-- MemberListProducer.java
|       |   |           |-- model
|       |   |           |   `-- Member.java
|       |   |           `-- util
|       |   |               `-- Resources.java
|       |   `-- resources
|       |       |-- import.sql
|       |       `-- META-INF
|       |           |-- beans.xml
|       |           `-- persistence.xml
|       `-- test
|           |-- java
|           |   `-- com
|           |       `-- foo
|           |           `-- test
|           |               `-- MemberRegistrationTest.java
|           `-- resources
|-- Foo-web
|   |-- pom.xml
|   `-- src
|       `-- main
|           |-- java
|           |   `-- com
|           |       `-- foo
|           |           `-- rest
|           |               |-- JaxRsActivator.java
|           |               `-- MemberResourceRESTService.java
|           `-- webapp
|               |-- index.html
|               |-- index.xhtml
|               |-- resources
|               |   |-- css
|               |   |   `-- screen.css
|               |   `-- gfx
|               |       |-- banner.png
|               |       `-- logo.png
|               `-- WEB-INF
|                   |-- beans.xml
|                   |-- faces-config.xml
|                   `-- templates
|                       `-- default.xhtml
|-- pom.xml
`-- README.md

32 directories, 23 files

Después de leer los cuatro archivos POM, que estaban bien comentados, tenía prácticamente toda la información que necesitaba.

./pom.xml
./Foo-ear/pom.xml
./Foo-ejb/pom.xml
./Foo-web/pom.xml
Patrick Garner
fuente
3
Esto funciona, pero termina poniendo un montón de dependencias específicas de jboss en su proyecto, que puede que desee o no limpiar después del hecho.
Ian McLaird
24

He creado un repositorio de github para mostrar lo que creo que es una buena (o mejores prácticas) estructura de proyecto de inicio ...

https://github.com/StefanHeimberg/stackoverflow-1134894

algunas palabras clave:

  • Maven 3
  • BOM (DependencyManagement de dependencias propias)
  • Principal para todos los proyectos (DependencyManagement de dependencias externas y PluginManagement para la configuración global del proyecto)
  • JUnit / Mockito / DBUnit
  • Proyecto Clean War sin WEB-INF / lib porque las dependencias están en la carpeta EAR / lib.
  • Proyecto Clean Ear.
  • Descriptores de implementación mínimos para Java EE7
  • No hay interfaz EJB local porque @LocalBean es suficiente.
  • Configuración mínima de maven a través de propiedades de usuario de maven
  • Descriptores de implementación reales para Servlet 3.1 / EJB 3.2 / JPA 2.1
  • uso de macker-maven-plugin para verificar las reglas de arquitectura
  • Pruebas de integración habilitadas, pero omitidas. (skipITs = false) útil para habilitar en CI Build Server

Salida de Maven:

Reactor Summary:

MyProject - BOM .................................... SUCCESS [  0.494 s]
MyProject - Parent ................................. SUCCESS [  0.330 s]
MyProject - Common ................................. SUCCESS [  3.498 s]
MyProject - Persistence ............................ SUCCESS [  1.045 s]
MyProject - Business ............................... SUCCESS [  1.233 s]
MyProject - Web .................................... SUCCESS [  1.330 s]
MyProject - Application ............................ SUCCESS [  0.679 s]
------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 8.817 s
Finished at: 2015-01-27T00:51:59+01:00
Final Memory: 24M/207M
------------------------------------------------------------------------
StefanHeimberg
fuente
2
Realmente me gusta su empaque y enfoque arquitectónico. Debería pensar en empaquetar su proyecto como un arquetipo de experto.
Jörg
2
¡Muy buena solución! Sin embargo, tengo una pregunta: ¿por qué no empaquetar el material de la lista de materiales en el proyecto principal? ¿Por qué la capa adicional?
sschober
1
causa de separación de preocupaciones. el bom podría ser importado por otros proyectos. solo necesitan la administración de dependencias de sus dependencias y no la administración de dependencias de las dependencias que está utilizando. Okay. puede decir que si nadie está usando su proyecto, esta capa adicional no es necesaria ... pero creo que también tiene sentido ... legibilidad. la gestión de dependencias del proyecto principal no se mezcla con sus dependencias ... en un proyecto más grande con> 50 proyectos internos de maven, la
gestión de
2
otra razón es que esta es la misma estructura que se documenta en maven.apache.org/guides/introduction/… . esto ayuda a trabajar en un equipo donde los miembros del equipo cambian a menudo porque es la forma documentada "predeterminada".
StefanHeimberg
2
Por cierto. He creado un proyecto de GitHub una vez para mostrar cómo se puede realizar una configuración de múltiples proyectos: github.com/StefanHeimberg/maven3-multiapplication-setup (para una discusión interna de la empresa)
StefanHeimberg
7

NetBeans IDE define automáticamente la estructura que es casi similar a la sugerida por Patrick Garner. Para usuarios de NetBeans

Archivo -> Nuevo proyecto -> En el lado izquierdo, seleccione Maven y en el lado derecho seleccione la Aplicación empresarial Maven y presione Siguiente -> Solicita nombres de proyectos para war, ejb y configuraciones.

El IDE creará automáticamente la estructura por usted.

desbordamiento de pila
fuente
Estoy de acuerdo con usted, especialmente cuando me adhiero a las especificaciones JEE6
Sym-Sym
3

Este es un buen ejemplo de la parte de maven-ear-plugin .

También puede consultar los arquetipos de maven que están disponibles como ejemplo. Si solo ejecuta mvn arquetipo: generate, obtendrá una lista de arquetipos disponibles. Uno de ellos es

maven-archetype-j2ee-simple
hcpl
fuente
10
maven-archetype-j2ee-simpleparece innecesariamente compleja en estructura, particularmente con módulos dentro de módulos y módulos separados para cosas como el registro. No entendí la razón detrás de esta estructura
Vihung
2

He estado buscando alto y bajo para un ejemplo de un extremo a otro de una aplicación completa empaquetada basada en maven y finalmente me encontré con esto . Las instrucciones dicen que seleccione la opción 2 cuando se ejecuta a través de la CLI, pero para sus propósitos, use la opción 1.

Roy Truelove
fuente
El enlace arroja un error no autorizado. Y esa es la razón para escribir soluciones completas en lugar de depender de enlaces.
Paco Abato