8

The project I'm working on is made of multiple modules, being built with maven. The test code in some modules has dependencies on test code from other modules. These dependencies are declared as below.

In the dependency module:

<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>

In the module which has the dependency on the previous module:

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>themodulename</artifactId>
    <version>${project.version}</version>
    <type>test-jar</type>
    <scope>test</scope>
</dependency>

Using this configuration, the maven install phase can be executed successfully. But trying to run the compile or test phase fails, because the test jar file dependency cannot be resolved.

Looking at the test-jar goal, it seems to be configured to run by default during the package phase, which I think is the cause of the problem.

Then, I tried to force this goal to run during the compile phase, by modifying the first config into:

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

Looking at the debug logs, I can see that the goal is now executed during the compile phase, but also this:

[WARNING] JAR will be empty - no content was marked for inclusion!

I tried to configure the includes to **/* and confirmed that the default testClassesDirectory was set to the right one, but I still get the same warning.

I could see that the test-classes folder didn't exist after running the compile phase, which seems normal, but even though it exists after running the test phase, and it contains files, I still get the "JAR will be empty" warning.

Does anyone have any idea on fixing this configuration so that I can run successfully the compile or test phase?

killy971
  • 650
  • 6
  • 16
  • Had a similar problem with some plugins. Interested. – Scorpio Aug 24 '12 at 07:10
  • 2
    Had a similiar problem yesterday, then I realized that I had the maven.skip.tests option set to true. Could it be somthing similar in your case? – pushy Aug 24 '12 at 07:18
  • your declaration **test-jar** seems a bit strange, could you show us the header of the pom of this related module ? – Farid Aug 24 '12 at 07:19
  • Why don't you wanna run `mvn install`? Take a look at the [Maven Lifecycle Reference](http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference). You should be able to use the `mvn package` command. – maba Aug 24 '12 at 07:19
  • @Farid What is strange about it? Looks fine to me. – Duncan Jones Aug 24 '12 at 07:29
  • @Duncan: assuming the dependency is a jar, its pom would normally be declared as **jar**, and therefore when refering to this artifact you would specify it using **jar** – Farid Aug 24 '12 at 07:33
  • @maba yes I should be able to run the *package* phase successfully, but it's just that I sometimes want to run only up to the *compile* or *test* phase. – killy971 Aug 24 '12 at 07:33
  • 2
    @Farid It is because he has followed this guide from Maven: http://maven.apache.org/guides/mini/guide-attached-tests.html – maba Aug 24 '12 at 07:35
  • @Farid *test-jar* seems to be a valid type, according to the page http://maven.apache.org/pom.html – killy971 Aug 24 '12 at 07:35
  • I see, thanks for link. i never used that type of declaration on my projects. I always use the traditional type jar approach on my multi module project even when there are module cross dependencies for unit tests. – Farid Aug 24 '12 at 07:42
  • See also https://stackoverflow.com/a/2532486/1072626 which looks to be similar to @RainYoung's answer below. – vossad01 Dec 15 '17 at 15:40

3 Answers3

6

I think that these plugin configuration works for you.

Just overwrite the skip to false in resources preparation and compiling.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <executions>
      <execution>
        <id>default-testResources</id>
        <configuration>
          <skip>false</skip>
        </configuration>
        <phase>process-test-resources</phase>
        <goals>
          <goal>testResources</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <executions>
      <execution>
        <id>default-testCompile</id>
        <configuration>
          <skip>false</skip>
        </configuration>
        <phase>test-compile</phase>
        <goals>
          <goal>testCompile</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <executions>
      <execution>
        <configuration>
          <skip>false</skip>
        </configuration>
        <goals>
          <goal>test-jar</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
Rain Young
  • 61
  • 1
  • 1
4

Your issue is down to dependency resolution in multi-module builds. It is not specifically related to test code.

I have exactly this setup. A common module contains runtime code along with shared test code (test doubles & mocks etc). The test code is used by tests in other modules. It works very well for us.

"mvn compile" only compiles runtime code.

Running an "mvn test-compile", "mvn test" or "mvn package" at the parent level (reactor build) everything works perfectly. The reactor can sort it all out.

If you run a build at the module level then all the depedencies of that module have to be in a repo. This means that you must have prevously run an "mvn install" for each of the dependent modules. This rule applies equally to both regular dependencies and test ones.

If you were hoping that it would follow the parent link up to the parent and down to the other modules I have to disappoint you. The parent link is only used to inherit common settings in the pom and not for dependency resolution.

Personally I almost always do a full reactor build from the parent. I only do an individual module build if I have previously run an mvn install at the parent level and I know the other modules haven't changed.

Hope that helps.

AutomatedMike
  • 1,454
  • 13
  • 27
2

I strongly believe that tests should only be part of one module. You should not depend on tests in other modules. It is very hard to predict what happens if you update the tests to behave differently.

If you need to share common test data or common test classes then it is better to create a separate module with that shared test source. And then let all tests have a dependency on the shared test-jar with scope test.

+-- MyProject
+-- common-test-util
|   +-- src
|   |    +-- main
|   |        +-- java
|   +-- pom.xml
+-- moduleA
|   +-- src
|   |    +-- main
|   |    |   +-- java
|   |    +-- test
|   |        +-- java
|   +-- pom.xml
+-- moduleB
|   +-- src
|   |    +-- main
|   |    |   +-- java
|   |    +-- test
|   |        +-- java
|   +-- pom.xml
+-- pom.xml

Make sure that you only depend on common-test-util with <scope>test</scope> and then you will be able to call

mvn test

on the top level and all tests will run.

maba
  • 47,113
  • 10
  • 108
  • 118
  • 4
    I respectfully dissagree. Mocks, Test Doubles, Stubs, Drivers and other test framework code is often usefully shared between modules but should not be included in runtime code. Building a common test-jar along with your regular common code jar works very well. Although of course I will agree that tests specific to the internals of the common jar shouldn't be used in other modules. You could separate these two categories of code but it is often not worth the effort. If you have a large test framework then make it a separate project of course. – AutomatedMike Aug 24 '12 at 09:58
  • 2
    @AutomatedMike That's more or less what I am saying. Put all that stuff in a jar and use in the different tests in other modules. But don't try to stuff it in `src/test/java`. Just put your actual tests there. – maba Aug 24 '12 at 10:03
  • 2
    @maba - moduleB is integration-tests, I have a dto in moduleA, I need to place a Fixture somewhere that I can use both in moduleA and moduleB. What's your suggestion in this case? – johnlemon May 05 '16 at 07:20