Question

By default maven surefile plugin run tests in isolated (forked) environment. You can override this behavior with following configuration:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
        <forkMode>never</forkMode>
      </configuration>
    </plugin>
  </plugins>
</build>

If you need to debug your tests you should to use this configuration snippet. Or you could simply run maven build the following way:

$ mvn -Dmaven.surefire.debug tests

This will starts a debugger on the port 5005.

My question is: what benefits have forking strategy and why is chosen as a default strategy for maven build? Isn't nonforking strategy is more straightforward and therefore should be used as default (maven is convention over configuration tool, right)?

Was it helpful?

Solution

My question is: what benefits have forking strategy and why is chosen as a default strategy for maven build?

By default, Surefire forks your tests using a manifest-only JAR. IMO, the main advantages are that:

  1. it provides an isolated environment with a somehow "correct" classpath.
  2. it protects the maven process itself (which is a good thing, especially if Maven is running embedded in your IDE).

Isn't nonforking strategy is more straightforward and therefore should be used as default?

Straightforward for what? Easy debugging inside an IDE? I believe that was not the initial intention (and I prefer to connect a remote debugger if the need arises and to keep the main Maven process safe).

See also

OTHER TIPS

forking mode helps to load system classpath if it is set to "true" or "once". But sometimes setting fork mode= true caues errors like "commmand line too long" or "there are test failures" if maven-surefire 2.5 plugin is used. To avoid this error its is recommended to ser forkmode=never whn using suefire plugin 2.5

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top