[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 {{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.
> 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)
