Dependencia de prueba de Maven en un proyecto de varios módulos

Utilizo maven para construir un proyecto de varios módulos. Mi módulo 2 depende del módulo 1 src en el alcance de compilación y las pruebas del módulo 1 en el alcance de la prueba.

Módulo 2 -

   <dependency>
       <groupId>blah</groupId>
       <artifactId>MODULE1</artifactId>
       <version>blah</version>
       <classifier>tests</classifier>
       <scope>test</scope>
   </dependency>

Esto funciona bien. Digamos que mi módulo 3 depende de Module1 src y las pruebas en tiempo de compilación.

Módulo 3 -

   <dependency>
       <groupId>blah</groupId>
       <artifactId>MODULE1</artifactId>
       <version>blah</version>
       <classifier>tests</classifier>
       <scope>compile</scope>
   </dependency>

Cuando ejecuto mvn clean install, mi compilación se ejecuta hasta el módulo 3, falla en el módulo 3 ya que no pudo resolver la dependencia de prueba del módulo 1. Luego hago un solo mvn installen el módulo 3, regreso y ejecuto mvn installen mi pom principal para que se compile. ¿Cómo puedo arreglar esto?

Tengo una duda sobre lo que está tratando de hacer, pero supongo que desea reutilizar las pruebas que ha creado para un proyecto (módulo1) en otro. Como se explica en la nota al final de la Guía para usar las pruebas adjuntas :

Tenga en cuenta que las ediciones anteriores de esta guía sugirieron usar en <classifier>tests</classifier>lugar de <type>test-jar</type>. Si bien esto funciona actualmente para algunos casos, no funciona correctamente durante la construcción del reactor del módulo JAR de prueba y cualquier consumidor si se invoca una fase del ciclo de vida antes de la instalación. En tal escenario, Maven no resolverá el JAR de prueba desde la salida de la construcción del reactor sino desde el repositorio local / remoto. Aparentemente, el JAR de los repositorios podría estar desactualizado o faltar por completo, provocando un error de compilación (cf. MNG-2045 ).

Entonces, primero, para empaquetar las pruebas compiladas en un JAR y desplegarlas para su reutilización general, configure el maven-jar-pluginsiguiente:

<project>
  <build>
    <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-jar-plugin</artifactId>
       <version>2.2</version>
       <executions>
         <execution>
           <goals>
             <goal>test-jar</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
    </plugins>
  </build>
</project>

Luego, instale / implemente el artefacto JAR de prueba como de costumbre (usando mvn installo mvn deploy).

Finalmente, para usar el JAR de prueba, debe especificar una dependencia con un tipo específico de test-jar:

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>com.myco.app</groupId>
      <artifactId>foo</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>test-jar</type>
      <scope>test</scope>
    </dependency>
  </dependencies>
  ...
</project>

Con respecto a mi comentario a la pregunta de Pascal, creo que he encontrado una respuesta adecuada:

<plugins>
    <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.2</version>
        <executions>
            <execution>
            <goals>
                <goal>test-jar</goal>
            </goals>
            <phase>test-compile</phase>
        </execution>
        </executions>
        <configuration>
            <outputDirectory>${basedir}\target</outputDirectory>
        </configuration>
    </plugin>
</plugins>

La principal diferencia aquí como ve aquí es la <phase>etiqueta.

Crearé el test-jar y estará disponible en la fase de compilación de las pruebas y no solo después de la fase de paquete.

Funciona para mi.

Como dice https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html :

Cómo crear un contenedor que contenga clases de prueba Cuando desee crear un contenedor que contenga clases de prueba, probablemente desee reutilizar esas clases. Hay dos formas de solucionar esto:

1. The easy way Cree un jar adjunto con las clases de prueba del proyecto actual y pierda sus dependencias transitivas de alcance de prueba.

2. The preferred way Cree un proyecto separado con las clases de prueba.

Por favor lea ese artículo para más detalles.