[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674086#comment-16674086
]
Stephane Nicoll edited comment on SUREFIRE-1198 at 11/3/18 3:47 PM:
I don't thinks that error is related to this issue. Spring Boot is using
Failsafe 2.22.1 in {{spring-boot-starter-parent}} with this extra configuration
{noformat}
${project.build.outputDirectory}
{noformat}
was (Author: snicoll):
I don't thinks that error is related to this issue. Spring Boot is using
Failsafe 2.22.1 in {{spring-boot-starter-parent}} with this extra configuration
{{noformat}}
${project.build.outputDirectory}
{{noformat}}
> Failsafe does not allow to configure the jar file to use
>
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.20
>
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674062#comment-16674062
]
Rustam Abdullaev edited comment on SUREFIRE-1198 at 11/3/18 2:32 PM:
-
Failsafe is NOT working with Spring Boot in repackage mode since version 2.19.
{code:java}
org.springframework.boot
spring-boot-maven-plugin
2.1.0.RELEASE
repackage
{code}
Causes
{code:java}
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:66)
at
org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:53)
at
org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:102)
at
org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.setTestsToRun(JUnit4Provider.java:189)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:132)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
{code}
So we're stuck with version *2.18.1* at the moment.
How to use Failsafe with the repackage goal?
was (Author: rustamabd):
Failsafe is NOT working with Spring Boot in repackage mode since version 2.19.
{code}
org.springframework.boot
spring-boot-maven-plugin
2.1.0.RELEASE
repackage
{code}
Causes
{code}
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:66)
at
org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:53)
at
org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:102)
at
org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.setTestsToRun(JUnit4Provider.java:189)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:132)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
{code}
So we're stuck with version *2.18.1* at the moment.
How to
[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519997#comment-15519997
]
Tibor Digana edited comment on SUREFIRE-1198 at 9/25/16 3:06 AM:
-
commit f1aea63320b66e635e0dc27e4f9ecd0e155099d9
commit 432231e7e9d01b9ef109acd39176045e0b18e5a5
was (Author: tibor17):
commit f1aea63320b66e635e0dc27e4f9ecd0e155099d9
> Failsafe does not allow to configure the jar file to use
>
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520012#comment-15520012
]
Phillip Webb edited comment on SUREFIRE-1198 at 9/25/16 2:30 AM:
-
{quote}I think here is the fundamental problem in Spring group using
integration tests{quote}
Just to be clear, the issue here was raised by Spring Boot *users*, we've not
hit the problem in our own build.
{quote}The ITs are inherently testing the interaction between jar files which
is the purpose. So I am wondering why if these jars can run in the application
server, the same file have problem to run in tests{quote}
Spring Boot creates "Fat Jar" files which a fully executable, there is no need
for an application server. The layout is conceptually similar to a WAR file.
Classes are under a {{BOOT-INF/classes}} folder and dependent libraries are
under {{BOOT-INF/lib}}. We have a custom {{URLHandler}} and {{Classloader}}
that actually launches the application.
{quote}I think it is unit tests started by maven-surefire-plugin which you
should rather use instead of maven-failsafe-plugin. Surefire tests classes in
particular module which is smaller granularity of tests.{quote}
I think it's a little confusing to suggest that users should switch to surefire
for integration tests, especially given that the plugin previously worked well.
I'm especially concerned that there is so much documentation out there for
using failsafe, and so many differences with configuration (e.g. the bound
lifecycle, the use of *IT.java) that it will be quite hard to explain why it
shouldn't be used.
I did look into how we might be able to plug in a different classloader, but
it's quite hard because most of the classpath is actually built in
{{AbstractSurefireMojo.generateTestClasspath}}. We really don't want to mess
with that, we just want to return a different JAR file (as it appeared before
we repackaged it) from {{getClassesDirectory()}} or failing that use the
{{project.build.outputDirectory}}.
I'm still wondering why we can't use the {{classesDirectory}} parameter. It
seems odd to me that the setting is completely ignored when dealing with
{{.jar}} files. I haven't had time to actually try the change yet, but I was
hoping to submit a PR that:
* Changed {{classesDirectory}} so that it no longer has a {{defaultValue}}.
* Updated {{getClassesDirectory()}} so that if {{classesDirectory}} is not
{{null}} it's returned
* Update the final line to {{return useArtifactFile ? artifactFile :
${project.build.outputDirectory};}}
Is that something that's worth pursuing? It seems a lot simpler than trying to
write another classloader, and I think it would be generally useful for any
project that does something different with the primary artifact JAR.
was (Author: pwebb):
> I think here is the fundamental problem in Spring group using integration
> tests
Just to be clear, the issue here was raised by Spring Boot *users*, we've not
hit the problem in our own build.
> The ITs are inherently testing the interaction between jar files which is the
> purpose. So I am wondering why if these jars can run in the application
> server, the same file have problem to run in tests
Spring Boot creates "Fat Jar" files which a fully executable, there is no need
for an application server. The layout is conceptually similar to a WAR file.
Classes are under a {{BOOT-INF/classes}} folder and dependent libraries are
under {{BOOT-INF/lib}}. We have a custom {{URLHandler}} and {{Classloader}}
that actually launches the application.
> I think it is unit tests started by maven-surefire-plugin which you should
> rather use instead of maven-failsafe-plugin. Surefire tests classes in
> particular module which is smaller granularity of tests.
I think it's a little confusing to suggest that users should switch to surefire
for integration tests, especially given that the plugin previously worked well.
I'm especially concerned that there is so much documentation out there for
using failsafe, and so many differences with configuration (e.g. the bound
lifecycle, the use of *IT.java) that it will be quite hard to explain why it
shouldn't be used.
I did look into how we might be able to plug in a different classloader, but
it's quite hard because most of the classpath is actually built in
{{AbstractSurefireMojo.generateTestClasspath}}. We really don't want to mess
with that, we just want to return a different JAR file (as it appeared before
we repackaged it) from {{getClassesDirectory()}} or failing that use the
{{project.build.outputDirectory}}.
I'm still wondering why we can't use the {{classesDirectory}} parameter. It
seems odd to me that the setting is completely ignored when dealing with
{{.jar}} files. I haven't had time to actually try the change yet, but I was
hoping to submit a PR that:
* Changed
[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15520012#comment-15520012
]
Phillip Webb edited comment on SUREFIRE-1198 at 9/25/16 2:31 AM:
-
{quote}I think here is the fundamental problem in Spring group using
integration tests{quote}
Just to be clear, the issue here was raised by Spring Boot *users*, we've not
hit the problem in our own build.
{quote}The ITs are inherently testing the interaction between jar files which
is the purpose. So I am wondering why if these jars can run in the application
server, the same file have problem to run in tests{quote}
Spring Boot creates "Fat Jar" files which a fully executable, there is no need
for an application server. The layout is conceptually similar to a WAR file.
Classes are under a {{BOOT-INF/classes}} folder and dependent libraries are
under {{BOOT-INF/lib}}. We have a custom {{URLHandler}} and {{Classloader}}
that actually launches the application.
{quote}I think it is unit tests started by maven-surefire-plugin which you
should rather use instead of maven-failsafe-plugin. Surefire tests classes in
particular module which is smaller granularity of tests.{quote}
I think it's a little confusing to suggest that users should switch to surefire
for integration tests, especially given that the plugin previously worked well.
I'm especially concerned that there is so much documentation out there for
using failsafe, and so many differences with configuration (e.g. the bound
lifecycle, the use of *IT.java) that it will be quite hard to explain why it
shouldn't be used.
I did look into how we might be able to plug in a different classloader, but
it's quite hard because most of the classpath is actually built in
{{AbstractSurefireMojo.generateTestClasspath}}. We really don't want to mess
with that, we just want to return a different JAR file (as it appeared before
we repackaged it) from {{getClassesDirectory()}} or failing that use the
{{project.build.outputDirectory}}.
I'm still wondering why we can't use the {{classesDirectory}} parameter. It
seems odd to me that the setting is completely ignored when dealing with
{{.jar}} files. I haven't had time to actually try the change yet, but I was
hoping to submit a PR that:
* Changed {{classesDirectory}} so that it no longer has a {{defaultValue}}.
* Updated {{getClassesDirectory()}} so that if {{classesDirectory}} is not
{{null}} it's returned
* Update the final line to {{return useArtifactFile ? artifactFile :
$\{project.build.outputDirectory\};}}
Is that something that's worth pursuing? It seems a lot simpler than trying to
write another classloader, and I think it would be generally useful for any
project that does something different with the primary artifact JAR.
was (Author: pwebb):
{quote}I think here is the fundamental problem in Spring group using
integration tests{quote}
Just to be clear, the issue here was raised by Spring Boot *users*, we've not
hit the problem in our own build.
{quote}The ITs are inherently testing the interaction between jar files which
is the purpose. So I am wondering why if these jars can run in the application
server, the same file have problem to run in tests{quote}
Spring Boot creates "Fat Jar" files which a fully executable, there is no need
for an application server. The layout is conceptually similar to a WAR file.
Classes are under a {{BOOT-INF/classes}} folder and dependent libraries are
under {{BOOT-INF/lib}}. We have a custom {{URLHandler}} and {{Classloader}}
that actually launches the application.
{quote}I think it is unit tests started by maven-surefire-plugin which you
should rather use instead of maven-failsafe-plugin. Surefire tests classes in
particular module which is smaller granularity of tests.{quote}
I think it's a little confusing to suggest that users should switch to surefire
for integration tests, especially given that the plugin previously worked well.
I'm especially concerned that there is so much documentation out there for
using failsafe, and so many differences with configuration (e.g. the bound
lifecycle, the use of *IT.java) that it will be quite hard to explain why it
shouldn't be used.
I did look into how we might be able to plug in a different classloader, but
it's quite hard because most of the classpath is actually built in
{{AbstractSurefireMojo.generateTestClasspath}}. We really don't want to mess
with that, we just want to return a different JAR file (as it appeared before
we repackaged it) from {{getClassesDirectory()}} or failing that use the
{{project.build.outputDirectory}}.
I'm still wondering why we can't use the {{classesDirectory}} parameter. It
seems odd to me that the setting is completely ignored when dealing with
{{.jar}} files. I haven't had time to actually try the change yet, but I was
hoping to submit a PR
[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504700#comment-15504700
]
Phillip Webb edited comment on SUREFIRE-1198 at 9/19/16 9:08 PM:
-
I spoke with [~rfscholte] a little about this issue today. One option we might
have is to find some way of plugging in a custom classloader that can deal with
Spring Boot's layouts. This does seem quite involved so I wondering if instead
we shouldn't look at what can be done with the {{getClassesDirectory()}}
method. Currently it looks like this:
{code:java}
public File getClassesDirectory()
{
Artifact artifact = getProject().getArtifact();
File artifactFile = artifact.getFile();
boolean useArtifactFile = artifactFile != null && artifactFile.isFile()
&& artifactFile.getName().toLowerCase().endsWith( ".jar" );
return useArtifactFile ? artifactFile : classesDirectory;
}
{code}
This is appears to be saying "use the main artifact, if it's a JAR, otherwise
use the classesDirectory". So, if the main artifact is set (which it will be if
failsafe is bound the expected lifecyle) there is no way to force the
{{classesDirectory}} to be used. Perhaps we could change that logic so that if
a specific {{classesDirectory}} attribute has been configured, it's always
used. That way Spring Boot could either set {{classesDirectory}} to
{{${project.build.outputDirectory}} to force use of the folder or, more likely,
set it to point to the original jar (before it was repackaged).
was (Author: pwebb):
I spoke with [~rfscholte] a little about this issue today. One option we might
have is to find some way of plugging in a custom classloader that can deal with
Spring Boot's layouts. This does seem quite involved so I wondering if instead
we shouldn't look at what can be done with the {{getClassesDirectory()}}
method. Currently it looks like this:
{code:java}
public File getClassesDirectory()
{
Artifact artifact = getProject().getArtifact();
File artifactFile = artifact.getFile();
boolean useArtifactFile = artifactFile != null && artifactFile.isFile()
&& artifactFile.getName().toLowerCase().endsWith( ".jar" );
return useArtifactFile ? artifactFile : classesDirectory;
}
{code}
This is appears to be saying "use the main artifact, if it's a JAR, otherwise
use the classesDirectory". So, if the main artifact is set (which it will be if
failsafe is bound the expected lifecyle) there is no way to force the
{{classesDirectory}} to be used. Perhaps we could change that logic so that a
specific {{classesDirectory}} attribute has been configured, it's always used.
That way Spring Boot could either set {{classesDirectory}} to
{{${project.build.outputDirectory}} to force use of the folder or, more likely,
set it to point to the original jar (before it was repackaged).
> Failsafe does not allow to configure the jar file to use
>
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357861#comment-15357861
]
Robert Scholte edited comment on SUREFIRE-1198 at 7/1/16 7:52 PM:
--
IIUC the Spring Boot jar is a jar-in-name-only: it doesn't follow the
specifications of a jar, classes are not in the root but in a subdirectory. I
assume you're using a custom classloader to execute this jar, which means that
the maven-failsafe-plugin should do the same.
was (Author: rfscholte):
IIUC the Spring Boot jar is a jar-in-name-only: it doesn't follow the
specifications of a jar, classes are not in the root but in a subdirectory. I
assume you're using a custom classloader to execute this jar, which means that
the maven-surefire-plugin should do the same.
> Failsafe does not allow to configure the jar file to use
>
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
