New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
JIIMI opened this Issue Jun 30, 2016 · 35 comments

Comments

Projects
None yet
@JIIMI

JIIMI commented Jun 30, 2016

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

@snicoll

This comment has been minimized.

Member

snicoll commented Jun 30, 2016

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

@snicoll

This comment has been minimized.

Member

snicoll commented Jun 30, 2016

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

This comment has been minimized.

JIIMI commented Jun 30, 2016

@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

This comment has been minimized.

Member

snicoll commented Jun 30, 2016

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

@JIIMI

This comment has been minimized.

JIIMI commented Jun 30, 2016

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

This comment has been minimized.

Member

wilkinsona commented Jun 30, 2016

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

This comment has been minimized.

Member

wilkinsona commented Jun 30, 2016

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

This comment has been minimized.

Member

snicoll commented Jun 30, 2016

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

This comment has been minimized.

JIIMI commented Jun 30, 2016

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 snicoll closed this in 6527aa0 Jun 30, 2016

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

@snicoll

This comment has been minimized.

Member

snicoll commented Jun 30, 2016

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

This comment has been minimized.

andrashatvani commented Jul 31, 2016

This should be documented in the release notes.

@snicoll

This comment has been minimized.

Member

snicoll commented Jul 31, 2016

@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

This comment has been minimized.

andrashatvani commented Jul 31, 2016

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

This comment has been minimized.

Member

snicoll commented Jul 31, 2016

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

@cecchisandrone

This comment has been minimized.

cecchisandrone commented Aug 8, 2016

Thanks!

@sepanniemi

This comment has been minimized.

sepanniemi commented Dec 7, 2016

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

This comment has been minimized.

Member

philwebb commented Dec 7, 2016

@sepanniemi It should work out the box.

@deepakab03

This comment has been minimized.

deepakab03 commented Feb 21, 2017

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

This comment has been minimized.

Member

wilkinsona commented Feb 21, 2017

@deepakab03 It hasn't been released yet

@deepakab03

This comment has been minimized.

deepakab03 commented Feb 21, 2017

okay, thanks!

@donovanmuller

This comment has been minimized.

donovanmuller commented Apr 28, 2017

@mihhail-lapushkin Just switched to 2.20 (using Spring Boot 1.5.3) and same issue. @deepakab03's workaround worked for me...

@mihhail-lapushkin

This comment has been minimized.

Contributor

mihhail-lapushkin commented Apr 28, 2017

Thanks! I am still using 2.18.1 to make it work.
My question was more about why 2.20 has not fixed the issue if the unreleased 2.19.2 contained the fix according to some commenters?

@srgg

This comment has been minimized.

srgg commented May 10, 2017

Also switched to use 2.20 and Spring Boot 1.5.3 and faced with the same issue... workaround rocks

RadekKoubsky added a commit to RadekKoubsky/rest_springboot-tomcat that referenced this issue Jun 8, 2017

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

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

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

@binkley

This comment has been minimized.

binkley commented Jun 8, 2017

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

This comment has been minimized.

binkley commented Jun 8, 2017

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 boxfuse/boxfuse-issues#174)

gytis added a commit to snowdrop/spring-boot-configmap-booster that referenced this issue Jun 12, 2017

Added goal 'repackage' to spring-boot-maven-plugin definition, see OB… (
#23)

* Added goal 'repackage' to spring-boot-maven-plugin definition, see OBST-273.

* Workaround for spring-projects/spring-boot#6254

gytis added a commit to snowdrop/spring-boot-http-booster that referenced this issue Jun 13, 2017

gytis added a commit to snowdrop/spring-boot-health-check-booster that referenced this issue Jun 13, 2017

@binkley

This comment has been minimized.

binkley commented Jun 15, 2017

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

See boxfuse/boxfuse-issues#174 (comment).

gytis added a commit to snowdrop/spring-boot-crud-booster that referenced this issue Jun 19, 2017

eddykaya pushed a commit to eddykaya/outfit_recommender that referenced this issue Jul 17, 2017

@hackmann

This comment has been minimized.

hackmann commented Nov 10, 2017

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

ryandawsonuk added a commit to Activiti/activiti-cloud-examples that referenced this issue Dec 14, 2017

Refactor connectors 3rd party (#43)
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

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

@mihab

This comment has been minimized.

mihab commented Feb 21, 2018

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

This comment has been minimized.

heruan commented Mar 8, 2018

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

@snicoll

This comment has been minimized.

Member

snicoll commented Mar 9, 2018

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

This comment has been minimized.

Member

wilkinsona commented May 2, 2018

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

This comment has been minimized.

rdp commented May 31, 2018

See also https://stackoverflow.com/q/42082131/32453 but...this feels unresolved somehow, should a new issue be raised with failsafe perhaps?

beatngu13 added a commit to retest/recheck-web that referenced this issue Jul 9, 2018

Downgrade to failsafe v2.18.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

roesslerj added a commit to retest/recheck-web that referenced this issue Jul 9, 2018

Downgrade to failsafe v2.18.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

This comment has been minimized.

naXa777 commented Sep 27, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment