views:

224

answers:

2

We're using the Maven exec:java goal to run a custom java application that configures a database for use with our integration tests. We want to use exec:java over exec:exec to be able to use the project dependencies in the classpath of the main class to be used. A few times the application has failed for valid reasons, but the Maven build continued as if nothing had gone wrong. Is there any "failonerror" type argument that can be used with exec:java? I'm afraid to add system.exit() codes to the class being run, as I suspect it will kill not only itself, but also Maven itself, due to the fact it's running in the Maven VM.

+1  A: 

This isn't a feature it has by default, but you might want to request it at http://jira.codehaus.org/browse/MEXEC, as it would be a simple addition.

If you want exec:java to fail the build, the main call will need to throw an exception instead of returning a non-zero exit code.

If that's not an option, you can still use exec:exec - see http://mojo.codehaus.org/exec-maven-plugin/examples/example-exec-for-java-programs.html for a description on how to add the project dependencies to the classpath.

A further option if neither of these suit for some reason is to use the AntRun plugin with the <java .../> task. Project dependencies can also be passed into that.

Brett Porter
Thanks Brett, I ended up using the antrun plugin in the end.
David Corley
+2  A: 

I just did a simple test with the following plugin configuration declared in a POM:

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.1</version>
        <executions>
          <execution>
            <id>my-exec-java</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>java</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <mainClass>com.example.Main</mainClass>
        </configuration>
      </plugin>
      ...
    </plugins>
    ...
  </build>
</project>

And the following Java class:

package com.example;

public class Main {
    public static void main(String[] args) {
        throw new RuntimeException("A problem occured");
    }
}

And this is what I get when invoking the integration-test phase:

$ mvn clean integration-test
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building q2363055
[INFO]    task-segment: [clean, integration-test]
[INFO] ------------------------------------------------------------------------

...

[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: /home/pascal/Projects/stackoverflow/q2363055/target/q2363055-1.0-SNAPSHOT.jar
[INFO] Preparing exec:java
[WARNING] Removing: java from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [exec:java {execution: my-exec-java}]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An exception occured while executing the Java class. null

A problem occured
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19 seconds
[INFO] Finished at: Tue Mar 02 23:40:32 CET 2010
[INFO] Final Memory: 16M/79M
[INFO] ------------------------------------------------------------------------

The integration phase is never executed, because of the build error.

So the question is, how are you handling errors in the Java class that loads your db? Is throwing an exception an option?

Pascal Thivent
Thanks Pascal. I've had an opportunity to look at the source and see a lot of unhandled errors. I believe your solution would work if the class being called had better exception handling. Thanks for the comprehensive answer!
David Corley