Maven-failsafe-plugin fails to execute integration tests #6254

JIIMI · 2016-06-30T07:47:23Z

When using the maven-filesafe-plugin the integration-test goal fails during build.

The following error happens under snapshot and 1.4.0.M3 versions. The same configuration is working fine under 1.3.5.RELEASE version.

Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:integration-test (default) on project demo: Execution default of goal org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:integration-test failed: There was an error in the forked process
java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:724)
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:531)
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:355)
at sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:286)
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:120)
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:72)
at java.lang.Class.createAnnotationData(Class.java:3521)
at java.lang.Class.annotationData(Class.java:3510)
at java.lang.Class.getAnnotation(Class.java:3415)
at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.isValidJUnit4Test(JUnit4TestChecker.java:65)
at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:52)
at org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:98)
at org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:311)
at org.apache.maven.surefire.junit4.JUnit4Provider.setTestsToRun(JUnit4Provider.java:191)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:134)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
-> [Help 1]

Plugins are configured in the following way:

<build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <configuration>
                    <includes>
                        <include>**/*IT.java</include>
                    </includes>
                </configuration>
            </plugin>
        </plugins>
</build>

I created a minimal project available here:
https://github.com/JIIMI/Spring-Boot-Maven-Failsafe-Plugin-Issue

The text was updated successfully, but these errors were encountered:

snicoll · 2016-06-30T07:54:32Z

@JIIMI thank you so much for the sample, very helpful.

snicoll · 2016-06-30T08:02:41Z

The same configuration is working fine under 1.3.5.RELEASE version.

That does not make much sense to me. If I paste the code snippet above, it doesn't invoke the failsafe plugin at all (there's no execution). If I put the definition of the failsafe plugin that is provided as of 1.4 in 1.3.5.RELEASE it breaks the same way. What I don't understand is that we've been using the feature quite a lot before adding it to the parent pom

If I remove the classes attributes on the SpringBootTest annotation, the exception goes away.

Maybe related this this SO thread?

JIIMI · 2016-06-30T08:17:56Z

@snicoll I'm glad it helped.
I tried removing the classes attribute before but got the following error:

initializationError(com.example.DemoApplicationIT)  Time elapsed: 0.002 sec  <<< ERROR!
java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test

With the following stack trace:

Running com.example.DemoApplicationIT
10:09:46.586 [main] DEBUG org.springframework.test.context.junit4.SpringJUnit4ClassRunner - SpringJUnit4ClassRunner constructor called with [class com.example.DemoApplicationIT]
10:09:46.597 [main] DEBUG org.springframework.test.context.BootstrapUtils - Instantiating CacheAwareContextLoaderDelegate from class [org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate]
10:09:46.611 [main] DEBUG org.springframework.test.context.BootstrapUtils - Instantiating BootstrapContext using constructor [public org.springframework.test.context.support.DefaultBootstrapContext(java.lang.Class,org.springframework.test.context.CacheAwareContextLoaderDelegate)]
10:09:46.635 [main] DEBUG org.springframework.test.context.BootstrapUtils - Instantiating TestContextBootstrapper for test class [com.example.DemoApplicationIT] from class [org.springframework.boot.test.context.SpringBootTestContextBootstrapper]
10:09:46.652 [main] INFO org.springframework.boot.test.context.SpringBootTestContextBootstrapper - Neither @ContextConfiguration nor @ContextHierarchy found for test class [com.example.DemoApplicationIT], using SpringBootContextLoader
10:09:46.659 [main] DEBUG org.springframework.test.context.support.AbstractContextLoader - Did not detect default resource location for test class [com.example.DemoApplicationIT]: class path resource [com/example/DemoApplicationIT-context.xml] does not exist
10:09:46.659 [main] DEBUG org.springframework.test.context.support.AbstractContextLoader - Did not detect default resource location for test class [com.example.DemoApplicationIT]: class path resource [com/example/DemoApplicationITContext.groovy] does not exist
10:09:46.660 [main] INFO org.springframework.test.context.support.AbstractContextLoader - Could not detect default resource locations for test class [com.example.DemoApplicationIT]: no resource found for suffixes {-context.xml, Context.groovy}.
10:09:46.662 [main] INFO org.springframework.test.context.support.AnnotationConfigContextLoaderUtils - Could not detect default configuration classes for test class [com.example.DemoApplicationIT]: DemoApplicationIT does not declare any static, non-private, non-final, nested classes annotated with @Configuration.
10:09:46.720 [main] DEBUG org.springframework.test.context.support.ActiveProfilesUtils - Could not find an 'annotation declaring class' for annotation type [org.springframework.test.context.ActiveProfiles] and class [com.example.DemoApplicationIT]
10:09:46.850 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding [systemProperties] PropertySource with lowest search precedence
10:09:46.850 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding [systemEnvironment] PropertySource with lowest search precedence
10:09:46.851 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized StandardEnvironment with PropertySources [systemProperties,systemEnvironment]
10:09:46.880 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Resolved classpath location [com/example/] to resources [URL [file:/D:/user/Documents/NetBeansProjects/!samples/Spring-Boot-Maven-Failsafe-Plugin-Issue/target/test-classes/com/example/]]
10:09:46.881 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Looking for matching resources in directory tree [D:\simjir.VCL\Documents\NetBeansProjects\!samples\Spring-Boot-Maven-Failsafe-Plugin-Issue\target\test-classes\com\example]
10:09:46.881 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Searching directory [D:\user\Documents\NetBeansProjects\!samples\Spring-Boot-Maven-Failsafe-Plugin-Issue\target\test-classes\com\example] for files matching pattern [D:/user/Documents/NetBeansProjects/!samples/Spring-Boot-Maven-Failsafe-Plugin-Issue/target/test-classes/com/example/*.class]
10:09:46.891 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Resolved location pattern [classpath*:com/example/*.class] to resources [file [D:\user\Documents\NetBeansProjects\!samples\Spring-Boot-Maven-Failsafe-Plugin-Issue\target\test-classes\com\example\DemoApplicationIT.class]]
10:09:46.928 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Resolved classpath location [com/] to resources [URL [file:/D:/user/Documents/NetBeansProjects/!samples/Spring-Boot-Maven-Failsafe-Plugin-Issue/target/test-classes/com/], URL [jar:file:/C:/Users/user/.m2/repository/com/fasterxml/classmate/1.3.1/classmate-1.3.1.jar!/com/], URL [jar:file:/C:/Users/user/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.7.4/jackson-databind-2.7.4.jar!/com/], URL [jar:file:/C:/Users/user/.m2/repository/com/fasterxml/jackson/core/jackson-annotations/2.7.4/jackson-annotations-2.7.4.jar!/com/], URL [jar:file:/C:/Users/user/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.7.4/jackson-core-2.7.4.jar!/com/], URL [jar:file:/C:/Users/user/.m2/repository/com/jayway/jsonpath/json-path/2.2.0/json-path-2.2.0.jar!/com/]]
10:09:46.929 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Looking for matching resources in directory tree [D:\user\Documents\NetBeansProjects\!samples\Spring-Boot-Maven-Failsafe-Plugin-Issue\target\test-classes\com]
10:09:46.929 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Searching directory [D:\user\Documents\NetBeansProjects\!samples\Spring-Boot-Maven-Failsafe-Plugin-Issue\target\test-classes\com] for files matching pattern [D:/user/Documents/NetBeansProjects/!samples/Spring-Boot-Maven-Failsafe-Plugin-Issue/target/test-classes/com/*.class]
10:09:46.930 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Looking for matching resources in jar file [file:/C:/Users/user/.m2/repository/com/fasterxml/classmate/1.3.1/classmate-1.3.1.jar]
10:09:46.934 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Looking for matching resources in jar file [file:/C:/Users/user/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.7.4/jackson-databind-2.7.4.jar]
10:09:46.974 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Looking for matching resources in jar file [file:/C:/Users/user/.m2/repository/com/fasterxml/jackson/core/jackson-annotations/2.7.4/jackson-annotations-2.7.4.jar]
10:09:46.975 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Looking for matching resources in jar file [file:/C:/Users/user/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.7.4/jackson-core-2.7.4.jar]
10:09:46.976 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Looking for matching resources in jar file [file:/C:/Users/user/.m2/repository/com/jayway/jsonpath/json-path/2.2.0/json-path-2.2.0.jar]
10:09:46.978 [main] DEBUG org.springframework.core.io.support.PathMatchingResourcePatternResolver - Resolved location pattern [classpath*:com/*.class] to resources []

snicoll · 2016-06-30T08:19:13Z

OK that's definitely interesting. It does not find your main spring boot class (which it definitely should).

JIIMI · 2016-06-30T08:46:00Z

For the:

The same configuration is working fine under 1.3.5.RELEASE version.

You're actually right, the maven-failsafe-plugin isn't invoked.
I didn't notice that as I was just looking for the build to succeed since I copied the configuration from our project where it gets invoked and suceeds.

I updated the project with the following configuration:

<plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <configuration>
                    <includes>
                        <include>**/*IT.java</include>
                    </includes>
                </configuration>
                <executions>
                    <execution>
                        <phase>integration-test</phase>
                        <goals>
                            <goal>integration-test</goal>
                            <goal>verify</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
</plugins>

Now the plugin gets invoked and the integration tests are properly run under version 1.3.5.RELEASE.

wilkinsona · 2016-06-30T08:48:31Z

This problem is due to a combination of a change in the Failsafe plugin and a change in the layout of a repackaged jar file in Boot 1.4. As of Failsafe 2.19, target/classes is no longer on the classpath and the project's built jar is used instead. In the case of a Boot app, that's the repackaged jar. In 1.4, the application's classes were moved from the root of the jar to the BOOT-INF/classes directory. This prevents them from being loaded by Failsafe.

wilkinsona · 2016-06-30T08:52:08Z

A workaround is to configure a classifier for the repackaged jar. This allows Failsafe to use the original jar:

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

snicoll · 2016-06-30T08:54:04Z

Another workaround is to downgrade to the maven-failsafe-plugin to 2.18.1. Funnily enough, I've actually reported the issue to the failsafe tracker but it got rejected.

JIIMI · 2016-06-30T08:55:39Z

Both indeed works. I guess keeping the 2.19.1 version should be better than using the old version.

@snicoll @wilkinsona Thank you both for your help.

snicoll · 2016-06-30T09:09:08Z

Unfortunately, the out-of-the-box experience would be very bad with 2.19 so I've reverted to 2.18. I'll follow up on the failsafe issue that I've reopened and once we have a more flexible solution I'll upgrade to 2.19 again.

Thanks for the report!

andrashatvani · 2016-07-31T16:31:31Z

This should be documented in the release notes.

snicoll · 2016-07-31T16:46:29Z

@andrashatvani what should be? If you're using the plugin management we provide, everything will work as advertized. So you'll have that issue only if you start overriding things. The release notes is a place to warn users about something we've actually changed. We didn't (the issue was introduced in a 1.4 milestone and fixed in RC).

andrashatvani · 2016-07-31T17:43:06Z

Sure, but I don't use the plugin management and I bet it's optional for a good reason i.e. we're not the only developers facing this issue. Just put the information in the release notes that one of the two workarounds is necessary if one upgrades to 1.4 and doesn't use the Spring Boot parent.

snicoll · 2016-07-31T18:26:50Z

You're right, thanks for not letting that go. I've added a section in the release notes.

cecchisandrone · 2016-08-08T14:56:07Z

Thanks!

sepanniemi · 2016-12-07T18:37:39Z

Would the fixed failsafe version 2.19.2 work with spring-boot 1.4.x out of the box or is there something else than just dependency update coming to 1.5.x?

philwebb · 2016-12-07T19:03:58Z

@sepanniemi It should work out the box.

deepakab03 · 2017-02-21T16:54:37Z

I faced the same issue while using spring boot 1.3.3.RELEASE, spring 4.2.5.RELEASE with maven-failsafe-plugin 2.19.1, and this post helped me to find a solution for he same.
As a possible fix to this as mentioned above, when I look at upgrading our maven-failsafe-plugin plugin version to 2.19.2 from 2.19.1, I found that 2.19.2 is not available at maven central: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22maven-failsafe-plugin%22 or at https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-failsafe-plugin
Also the documentation page for this plugin states that the latest version is http://maven.apache.org/surefire/maven-failsafe-plugin/index.html is 2.19.1 as of today, so where is this 2.19.2 version published?

Edit:
in our case we had some resources in the classes folder that was not added to the jar, but that were used by the tests, to work around it we add the target\classes as an additional classpath element.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <configuration>
        <includes>
            <include>**/*IT.java</include>
        </includes>
            <additionalClasspathElements>
                <additionalClasspathElement>${basedir}/target/classes</additionalClasspathElement>
            </additionalClasspathElements>
            <parallel>none</parallel>
    </configuration>
    <executions>
        <execution>
            <id>integration-test</id>
            <phase>integration-test</phase>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>`

wilkinsona · 2017-02-21T17:14:23Z

@deepakab03 It hasn't been released yet

deepakab03 · 2017-02-21T17:15:48Z

okay, thanks!

binkley · 2017-06-08T15:45:37Z

The exec classifier works for me, but is unfortunate. I also use Boxfuse, which builds a unikernel from the jar, and as the Spring Boot jar has a classifier, Boxfuse picks the wrong jar (the original, un-springified one).

Currently I'm using:

Spring Boot 2.0.0.M1
Failsafe 2.20
Boxfuse whatever-is-current (is updates frequently)

Is there a roadmap to get failsafe working out of the box without the exec workaround?

binkley · 2017-06-08T16:10:36Z

Following a trail of clues, I found an alternative workaround is to restore the behavior in 2.19+ of using target/classes as did 2.18-:

http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#classesDirectory

So I removed the exec classifier, and added to my failsafe plugin configuration:

<classesDirectory>${project.build.outputDirectory}</classesDirectory>

This allowed both mvn verify and mvn boxfuse:run -Denv=dev to run with the same pom.xml. (FYI, there were other issues, but those relate to boxfuse and Boot 2.x, not to failsafe! -- see cloudcaptainsh/cloudcaptain#174)

#23) * Added goal 'repackage' to spring-boot-maven-plugin definition, see OBST-273. * Workaround for spring-projects/spring-boot#6254

binkley · 2017-06-15T12:28:23Z

I found workaround for using both a renamed spring boot uber jar and boxfuse together.

See cloudcaptainsh/cloudcaptain#174 (comment).

hackmann · 2017-11-10T13:14:05Z

As an alternative to use target/classes use the original jar before it was repackaged

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <!--
                 Make failsafe and spring-boot repackage play nice together
                -->
                <configuration>
                    <classesDirectory>${project.build.directory}/${artifactId}.jar.original</classesDirectory>
                </configuration>
            </plugin>

This is more in line with failsafe's of testing the packaged jar file instead of the classes

Refactor connectors 3rd party to use constructor injection instead of field inject and use strategy pattern to select the call strategy (with or without SLA). Had to downgrade failsafe version due to spring-projects/spring-boot#6254

mihab · 2018-02-21T11:04:37Z

Is there a particular reason why I still need to add this for Spring Boot 2.0 RC1?

exec

ITs fail without it and failsafe plugin.

heruan · 2018-03-08T21:25:56Z

Same here. Which is nowadays the correct way to make Spring Boot (now 2.0) work with the Failsafe plugin? Any example project?

snicoll · 2018-03-09T08:47:37Z

This issue is closed and we don't use the tracker for questions: please ask on StackOverflow or join us on Gitter. If you believe you've found an issue with the way the failsafe plugin is configured, please raise a separate issue with a sample that reproduces the problem.

wilkinsona · 2018-05-02T10:25:38Z

Thanks for try to help people out, @mmuller88, but JUnit 5 is compatible with Maven. The JUnit team maintain a Maven-based sample. Spring Boot also has its own JUnit 5 sample that uses Maven.

rdp · 2018-05-31T23:54:10Z

See also https://stackoverflow.com/q/42082131/32453 but...this feels unresolved somehow, should a new issue be raised with failsafe perhaps? (FWIW 2.18.1 worked better for me than 2.19.1)

Essentially, newer versions test against the JAR, whereas until v2.18.1 failsafe uses test-class. Somehow the JAR creates problems when resources such as the attributes.yml are needed. See also: * https://stackoverflow.com/questions/42082131/maven-surefire-verify-java-lang-classnotfoundexception * spring-projects/spring-boot#6254

naXa777 · 2018-09-27T08:48:29Z

Take a look at this question https://stackoverflow.com/q/49363222/1429387

AndreiOprisan94 · 2019-07-09T10:31:47Z

I just added the post-integration-test phase

                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>${springframework.boot.version}</version>
                <configuration>
                    <mainClass>com.example.MainClass</mainClass>
                    <layout>JAR</layout>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                        <phase>post-integration-test</phase>
                    </execution>
                </executions>

sparrowV · 2021-01-27T18:16:24Z

adding surefire dependency works for me, dont know exactly why though

<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-failsafe-plugin</artifactId>
			<version>3.0.0-M5</version>
				<dependencies>
					<dependency>
						<groupId>org.apache.maven.surefire</groupId>
						<artifactId>surefire-junit47</artifactId>
						<version>3.0.0-M5</version>
					</dependency>
				</dependencies>
			<executions>
				<execution>

					<goals>
						<goal>integration-test</goal>
						<goal>verify</goal>
					</goals>
				</execution>
			</executions>

			</plugin>

lsublimitl · 2021-06-22T12:05:31Z

Using Failsafe plugin without parent spring-boot dependency and having a custom directory build path I got this working with the next code:

    <build>
        <directory>docker/app</directory>
        <plugins>
	    ...
	    <plugin>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>3.0.0-M5</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>integration-test</goal>
                            <goal>verify</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <classesDirectory>${project.build.directory}/classes</classesDirectory>
                </configuration>
            </plugin>
	     ...
        </plugins>
    </build>

sudoHackIn · 2021-12-04T12:13:53Z

works for me too

Marks13 · 2024-03-29T08:41:23Z

Using Failsafe plugin without parent spring-boot dependency and having a custom directory build path I got this working with the next code:

    <build>
        <directory>docker/app</directory>
        <plugins>
	    ...
	    <plugin>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>3.0.0-M5</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>integration-test</goal>
                            <goal>verify</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <classesDirectory>${project.build.directory}/classes</classesDirectory>
                </configuration>
            </plugin>
	     ...
        </plugins>
    </build>

As of March 2024 this is still up to date.

spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 30, 2016

snicoll self-assigned this Jun 30, 2016

snicoll added type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Jun 30, 2016

JIIMI mentioned this issue Jun 30, 2016

added issue #6254 spring-attic/spring-boot-issues#54

Closed

snicoll closed this as completed in 6527aa0 Jun 30, 2016

snicoll added this to the 1.4.0.RC1 milestone Jun 30, 2016

philwebb mentioned this issue Jun 30, 2016

Upgrade to Failsafe with SUREFIRE-1198 #6259

Closed

snicoll mentioned this issue Oct 5, 2016

Maven's Failsafe Plugin Does Not Work With Spring Boot Maven Plugin's Repack Goal #7095

Closed

binkley mentioned this issue Dec 10, 2016

Add integration test for endpoint binkley/sproingk#3

Closed

RadekKoubsky added a commit to RadekKoubsky/spring-boot-configmap-booster that referenced this issue Jun 8, 2017

Workaround for spring-projects/spring-boot#6254

ac2b4f7

gytis pushed a commit to snowdrop/rest-http-example that referenced this issue Jun 13, 2017

Workaround for spring-projects/spring-boot#6254 (#45)

c69ab87

gytis pushed a commit to snowdrop/health-check-example that referenced this issue Jun 13, 2017

Workaround for spring-projects/spring-boot#6254 (#5)

7c3768e

gytis pushed a commit to snowdrop/crud-example that referenced this issue Jun 19, 2017

Workaround for spring-projects/spring-boot#6254 (#7)

31106f1

aegershman mentioned this issue Nov 22, 2017

Run mvn failsafe itest goals directly vmware-archive/pipeline-tasks#10

Closed

evainga referenced this issue in evainga/rememberbrall Jan 18, 2018

Fix TypeNotPresentExceptionProxy problem with workaround

fcc1309

snicoll mentioned this issue Feb 9, 2018

Failsafe plugin does not add production code of the module to the classpath #11974

Closed

coollog mentioned this issue May 14, 2018

Fixes Maven integration tests. GoogleContainerTools/jib#272

Merged

DanielFran mentioned this issue Mar 6, 2019

Add maven-failsafe-plugin and separate unit from integration tests jhipster/generator-jhipster#9337

Merged

4 tasks

NWinocur mentioned this issue Mar 12, 2019

Update junixsocket to v2.2.0 to support ARM, Win10 NWinocur/docker-java#1

Open

sbrannen mentioned this issue Mar 3, 2021

Document how to configure Maven's Failsafe plugin when not using spring-boot-starter-parent #25473

Closed

Maven-failsafe-plugin fails to execute integration tests #6254

Maven-failsafe-plugin fails to execute integration tests #6254

Comments

JIIMI commented Jun 30, 2016 • edited by philwebb

snicoll commented Jun 30, 2016

snicoll commented Jun 30, 2016 • edited

JIIMI commented Jun 30, 2016 • edited

snicoll commented Jun 30, 2016

JIIMI commented Jun 30, 2016 • edited by philwebb

wilkinsona commented Jun 30, 2016

wilkinsona commented Jun 30, 2016

snicoll commented Jun 30, 2016

JIIMI commented Jun 30, 2016

snicoll commented Jun 30, 2016

andrashatvani commented Jul 31, 2016

snicoll commented Jul 31, 2016

andrashatvani commented Jul 31, 2016 • edited

snicoll commented Jul 31, 2016

cecchisandrone commented Aug 8, 2016

sepanniemi commented Dec 7, 2016

philwebb commented Dec 7, 2016

deepakab03 commented Feb 21, 2017 • edited

wilkinsona commented Feb 21, 2017

deepakab03 commented Feb 21, 2017

binkley commented Jun 8, 2017

binkley commented Jun 8, 2017 • edited

binkley commented Jun 15, 2017

hackmann commented Nov 10, 2017

mihab commented Feb 21, 2018

heruan commented Mar 8, 2018 • edited

snicoll commented Mar 9, 2018

wilkinsona commented May 2, 2018

rdp commented May 31, 2018 • edited

naXa777 commented Sep 27, 2018

AndreiOprisan94 commented Jul 9, 2019 • edited

sparrowV commented Jan 27, 2021 • edited

lsublimitl commented Jun 22, 2021 • edited

sudoHackIn commented Dec 4, 2021

Marks13 commented Mar 29, 2024

JIIMI commented Jun 30, 2016 •

edited by philwebb

snicoll commented Jun 30, 2016 •

edited

JIIMI commented Jun 30, 2016 •

edited

JIIMI commented Jun 30, 2016 •

edited by philwebb

andrashatvani commented Jul 31, 2016 •

edited

deepakab03 commented Feb 21, 2017 •

edited

binkley commented Jun 8, 2017 •

edited

heruan commented Mar 8, 2018 •

edited

rdp commented May 31, 2018 •

edited

AndreiOprisan94 commented Jul 9, 2019 •

edited

sparrowV commented Jan 27, 2021 •

edited

lsublimitl commented Jun 22, 2021 •

edited