Tengo un proyecto Maven de varios módulos. Por el bien de este ejemplo, considere dos módulos:
data
consumer
Módulo consumer
tiene modulo data
como dependencia.
Módulo data
declara un montón de clases principales. Hay pruebas bajo src/test
que los use. Estas pruebas requieren una creación de objetos prolija, por lo que tengo una clase con algunos métodos de utilidad para crear estos objetos. Esta clase de utilidad (SampleDataHelper
) está en el src/test
jerarquía.
También tengo algunas pruebas en el consumer
módulo que necesita para crear algunos de estos objetos de largo aliento. quiero usar mi SampleDataHelper
clase (definida en data src/test
) en las pruebas que residen en mi consumer src/test
árbol. Desafortunadamente, aunque data
es una dependencia de consumer
, consumer
no puedo ver las clases que existen bajo data src/test
.
Para combatir esto, pensé que podría crear otro módulo (data-test
), y mover SampleDataHelper
debajo src/main
. Entonces incluiría data-test
como un ámbito de prueba dependencia de data
. Desafortunadamente, esto introduce una dependencia circular: data
usos data-test
pero data-test
también requiere data
.
La única solución que he encontrado es colocar SampleDataHelper
por debajo data src/main
debajo de test
paquete y espero que ningún código de aplicación real lo llame.
¿Cómo puedo compartir mi SampleDataHelper
clase entre módulos sin que poniéndolo debajo src/main
?
duncan jones
Su proyecto de Consumidor depende de su proyecto de Datos, por lo tanto, nos complace que los Datos deban construirse antes que los de Consumidor. Como resultado, usando las técnicas sugeridas en los comentarios, me aseguraría de que su proyecto de datos contenga todo el código de prueba que desea compartir y configurar el POM para producir un JAR de prueba:
<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>
Su proyecto de Consumidor dependería tanto del artefacto Data JAR normal como del adicional test-jar
artefacto, con alcance de prueba, por supuesto:
<dependency>
<groupId>com.foo</groupId>
<artifactId>data</artifactId>
<version>1.0</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
He usado este enfoque en muchas ocasiones y funciona bien.
-
con respecto a “Su proyecto de Consumidor dependería tanto del artefacto Data JAR normal, como de la parte adicional del artefacto jar de prueba”, cuando agrego ambas dependencias de datos en el consumidor (digamos que mis artefactos también se denominan datos y consumidor) pom, sin especificación de versiones específicas, el pom obtuvo un error. ¿Por qué sucede eso?
– Juan
20 de agosto de 2015 a las 13:17
-
@StasS probablemente sea mejor que abra una pregunta separada sobre eso.
–Duncan Jones
21 de agosto de 2015 a las 11:39
-
Lo hice 🙂 stackoverflow.com/questions/32119591/…
– Juan
21 de agosto de 2015 a las 12:57
Matsev
Así que el problema es que (algunas) pruebas en el data
módulo depende de la SampleDataHelper
¿clase? Puedes mover el SampleDataHelper
clase a src/main
del data-test
módulo, si al mismo tiempo mueve las pruebas (que dependen de la clase específica) al src/test
del data-test
módulo. En consecuencia, no habría más dependencias circulares.
-
Si lo entiendo, está sugiriendo que cualquier prueba que use
SampleDataHelper
ser movido desde eldata
módulo o elconsumer
módulo (según corresponda) endata-test
. Desafortunadamente, no encuentro que esta sea una solución muy “limpia”, ya que mueve mis pruebas fuera del módulo que prueban y dentro de uno diferente. (Estrictamente hablando, solo dijiste que movieras eldata
pruebas, pero creo que me encontraría moviendo ambos por consistencia). Pero gracias por tu respuesta. 🙂– Greg Kopff
6 de febrero de 2013 a las 6:48
-
Sí, me entendiste bien. Y podría decirse que es más una solución rápida que una buena. 🙂
– Matsev
6 de febrero de 2013 a las 7:48
-
Me imagino que las dependencias circulares permanecerían. Suponiendo que las pruebas en cuestión ejerzan las clases definidas en el proyecto de datos, aún sería necesario que hubiera una referencia al proyecto de datos desde el proyecto de prueba de datos.
–Duncan Jones
6 de febrero de 2013 a las 7:49
-
@DuncanJones Lo siento, hubo un pequeño error tipográfico en mi publicación. El punto que estoy tratando de hacer es que el
data-test
El módulo debe depender deldata
módulo (y no al revés). Para evitar la dependencia circular, todas las pruebas que residen actualmente en eldata
módulo que utiliza elSampleDataHelper
debe trasladarse a ladata-test
módulo.– Matsev
6 de febrero de 2013 a las 8:15
-
Te tengo, eso tiene más sentido.
–Duncan Jones
6 de febrero de 2013 a las 9:47
Mira esta respuesta. Creo que debería ayudarte.
– Andrew Logvinov
6 de febrero de 2013 a las 6:31
Para futuros lectores: Guía Maven para usar pruebas adjuntas
– Greg Kopff
6 de febrero de 2013 a las 6:36
@AndrewLogvinov: ¿su respuesta vinculada no requeriría una compilación de “dos pasos”? Para construir primero y desplegar un módulo (
data
) antes de que pueda compilar mi segundo módulo (consumer
).– Greg Kopff
6 de febrero de 2013 a las 6:42
creo que usted puede que encuentra algunos problemas si usa
mvn package
pero debería funcionar bien en una compilación de un solo paso cuando usamvn install
omvn deploy
. Solo una nota rapida. En uno de nuestros grandes proyectos tenemos un wrapper sobre junit’sTestBase
y se encuentra ensrc/main
que tampoco considero una buena idea.– Andrew Logvinov
6 de febrero de 2013 a las 6:58