TypeNotPresentExceptionProxy error at integration-test with maven-failsafe-plugin spring-boot 1.4

Question

I'm getting ArrayStoreException: TypeNotPresentExceptionProxy when running integration-test with maven-failsafe-plugin and spring-boot 1.4.

You can see this error if you run joinfaces-example with

mvn -Pattach-integration-test clean install

I realized that the error does not occur if I change spring-boot-maven-plugin to run at pre-integration-test phase instead of package one.

More, this error started when I upgraded spring boot to 1.4. No error occurs if I change jsf-spring-boot-parent version to 2.0.0 which uses spring boot 1.3 version.

Answer 1

I actually found the answer in Spring Boot 1.4 release notes, short answer is that maven-failsafe-plugin is not compatible with Spring Boot 1.4's new executable layout. Full explanation below :

As of Failsafe 2.19, target/classes is no longer on the classpath and the project’s built jar is used instead. The plugin won’t be able to find your classes due to the change in the executable jar layout. There are two ways to work around this issue:

• Downgrade to 2.18.1 so that you use target/classes instead

• Configure the spring-boot-maven-plugin to use a classifier for the repackage goal. That way, the original jar will be available and used by the plugin. For example :

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <classifier>exec</classifier>
    </configuration> 
</plugin>

Answer 2

An alternative is documented here: https://github.com/spring-projects/spring-boot/issues/6254

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <!--
        Make failsafe and spring-boot repackage play nice together,
        see https://github.com/spring-projects/spring-boot/issues/6254
    -->
    <configuration>
        <classesDirectory>${project.build.outputDirectory}</classesDirectory>
    </configuration>
</plugin>

This worked better for me, because when I used the "exec" solution, Spring failed to find my configuration files when starting the container. Which could probably be fixed by adding some further configuration parameters, I suppose, but this solution works "out of the box" for me.