java-maven2: Wie schließe ich ein jar als Abhängigkeit in pom ein, so dass ich in der Lage bin, auf Testklassen oder Klassen im Ordner src/test/java zuzugreifen?

Question

Ich habe eine Reihe von funktionalen jars (mehr als 3), die meinen Quellcode testet. Diese Jars enthält nur Testklassen und assistierende Asserter Klassen. Ich erstelle eine neue Performance-Jar, die alle funktionalen Tests aus diesen Jars importieren würde, so dass alle gleichzeitig ausgeführt werden können. Aber wenn ich sie als Testabhängigkeiten in pom des aktuellen Jars einfüge, bekomme ich nur die Klassen in src/main/java zu sehen. Wie kann ich diese funktionalen Jars als abhängige Jars einschließen, so dass ich auch Klassen in src/test/java referenzieren kann. Mit anderen Worten, wie kann ich auf die Testklassen in anderen Jars verweisen. Auf welche Weise sollte ich die Abhängigkeit als einschließen.

Vielen Dank für Ihre Unterstützung.

Answer 1

Erste Option

Legen Sie Ihren gemeinsamen "Test"-Code in ein separates Modul (in src/main/java ) und deklarieren eine Abhängigkeit von diesem Modul mit einem test Bereich in Modulen, die den gemeinsamen Code benötigen:

<dependency>
  <groupId>my.group.id</groupId>
  <artifactId>testing-framework</artifactId>
  <version>${project.version}</version>
  <scope>test</scope>
</dependency>

Das ist eine gängige Praxis, daran ist nichts auszusetzen.

Zweite Option

Verwenden Sie die Maven JAR-Plugin und seine jar:test-jar Ziel ist es eine JAR-Datei mit den Testklassen für das aktuelle Projekt erstellen als Teil der package Phase ( jar:test-jar bindet sich standardmäßig an package ):

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

Um das angehängte Test-JAR, das oben erstellt wurde, zu verwenden, wird empfohlen, eine Abhängigkeit vom Hauptartefakt mit einem bestimmten Typ von 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>

Siehe die Diskussion am Ende der Seite Leitfaden zur Verwendung beigefügter Tests aus welchen Gründen <type>test-jar</type> sollte vorgezogen werden gegenüber <classifier>tests</classifier> .

Answer 2

Der Code in src/test/java ist standardmäßig nicht in der Jarbox enthalten (ich halte das für eine gute Sache und wäre vorsichtig damit, es zu ändern, selbst wenn ich es könnte).

Ich finde, dass gemeinsamer Testcode in einem separaten Maven-Modul in der src/main/java eine sehr gute Praxis zu sein. Binden Sie dieses Modul dann einfach als testspezifische Abhängigkeit ein, wenn Sie es benötigen.

Answer 3

Entweder Sie gehen den Weg, der von Lauri oder verwenden Sie eine leichte Variante, bei der Sie kein dediziertes Test-Artefakt haben, sondern ein Commons-Artefakt, das auch gemeinsame Testklassen in src/test/java enthält.

Verwenden Sie in diesem Projekt die test-jar mojo zum Erstellen und Anhängen des Test-Jars dieses Projekts

In abgeleiteten Projekten können Sie die Abhängigkeit nun wie folgt einbinden:

<dependency>
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <version>...</version>
    <scope>test</scope>
    <classifier>test</classifier>
</dependency>

Auf diese Weise müssen Sie kein separates Testprojekt erstellen, wenn Sie bereits ein Commons-Projekt haben.

Answer 4

mvn package keine Testklassen und Ressourcen blockiert. Sie müssen also die Abhängigkeiten in src/main/java einfügen.

Wenn ich dies tue, erstelle ich ein Jar-Projekt mit dem Namen "someproj-testutils" und habe Hilfsklassen oder Basistestklassen und Ressourcen in der normalen src/main/ und verweisen dann auf someproj-testutils als eine testspezifische Abhängigkeit.