2012-06-22 17 views
6

Soy nuevo en Maven y estoy tratando de convertir algunos proyectos para trabajar en Maven y no estoy seguro de cuál es la forma correcta de estructurarlos - esto es lo que tener:Diseño de proyecto Maven - compartiendo un proyecto en común

Tengo un módulo común - llamado Common y dos aplicaciones diferentes que no tienen nada en común, ya que ambos dependen de Common. Vamos a llamarlos A y B.

Las dependencias entre A ->Common y B ->Common son tanto para el tiempo de ejecución y para las pruebas - lo que significa que A 's clases de prueba requieren Common' s clases de prueba.

Probé varias combinaciones que pude pensar, pero ninguna de ellas produjo lo que quería. Lo extraño es que mi código se compila, pero JUnits falla ya que las clases de prueba de Common no se encuentran en la ruta de clases.

¿Debo agregar 2 perfiles al Common para crear 2 artefactos y agregar 2 dependencias en A y B a ambos artefactos? (¿Es eso posible?) ¿Hay una manera correcta de hacer lo que yo quería? ¿Debo reestructurar mi código para que coincida con Maven?

Respuesta

5

Esto es un error de maven común. Las clases de prueba de un artefacto no están disponibles cuando dependes de ese artefacto. En realidad es razonable: cuando dependes de Common, dependes de las clases de producción (archivo JAR). Las clases de prueba solo son necesarias para ejecutar pruebas y ni siquiera están incluidas en el JAR final.

Asumiendo que su Common clases de prueba contienen algún método utilidad necesaria para todos los Common pruebas, A y B pruebas, aquí es una estructura sugerida:

  • Common-test - que contiene las clases de prueba de utilidad común (no probar los casos!) En /src/main/java (!)
  • Common depende de Common-test con <scope>test</scope>
  • A y B dependerá tanto Common (con ámbito predeterminado) y Common-test (con test alcance)

UML

+0

cool, ¿qué herramienta utilizaste para dibujarlo? –

+0

¿Qué usaste para hacer este diagrama? Se ve limpio. – zengr

+2

@zengr: http://yuml.me/ –

2

Se podría estructurar como si fuera

  • proyecto común
  • Un proyecto
  • el proyecto B

Ahora agregue CommonProject a <dependency> para A & B, que hará que el commonproject disponible en Tiempo de compilación para que la compilación sea buena,

Si su Un & B es o arquetipo webapp entonces usted necesita para asegurarse de que sus dependencias están disponibles en WEB-INF/lib de forma que pueda obtener las dependencias en tiempo de ejecución

Para hacer que las dependencias disponible sólo en test tiempo, puede usar test scope

2

Tienes que correr test-jar objetivo de maven-jar-plugin en su proyecto Common.

Esto produce un nuevo artefacto con el clasificador tests, que contiene todas las clases y recursos del árbol src/test.

Así pues, en común añadir lo siguiente:

<plugins> 
    ... 
    <plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-jar-plugin</artifactId> 
    <executions> 
     <execution> 
     <id>test-jar</id> 
     <goals> 
      <goal>test-jar</goal> 
     </goals> 
     </execution> 
    </executions> 
    </plugin> 
    ... 
</plugins> 

Y en A y B añadir esta

<dependency> 
    <groupId>common.group.id</groupId> 
    <artifactId>Common</artifactId> 
    <version>1.0</version> 
    <classifier>tests</classifier> 
    <scope>test</scope> 
</dependency> 

Nota <classifier>tests</classifier> en esta declaración de dependencia.

+0

Gracias, ese fue el truco. Pero por lo que he leído, esta podría no ser la arquitectura recomendada, ¿es correcto? ¿Es mejor la respuesta proporcionada por Tomasz Nurkiewicz (http://stackoverflow.com/a/11161411/357360) desde un POV de arquitectura maven? – RonK

+0

@RonK. Yo diría, si los recursos 'Common/src/test' contienen puertas traseras para crear objetos de prueba en' Common', use mi enfoque. Si las clases allí contienen arneses y marcos de prueba comunes, use el enfoque de Tomasz. –

Cuestiones relacionadas