Uploaded image for project: 'Maven Surefire'
  1. Maven Surefire
  2. SUREFIRE-1198

Failsafe does not allow to configure the jar file to use

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.20
    • Component/s: None
    • Labels:
      None

      Description

      See this Spring Boot issue

      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)

        Issue Links

          Activity

          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Jenkins build maven-surefire #1627 (See https://builds.apache.org/job/maven-surefire/1627/)
          SUREFIRE-1198 Failsafe does not allow to configure the jar file to use (tibor17: rev 432231e7e9d01b9ef109acd39176045e0b18e5a5)

          • (edit) maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Jenkins build maven-surefire #1627 (See https://builds.apache.org/job/maven-surefire/1627/ ) SUREFIRE-1198 Failsafe does not allow to configure the jar file to use (tibor17: rev 432231e7e9d01b9ef109acd39176045e0b18e5a5) (edit) maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in Jenkins build maven-surefire #1626 (See https://builds.apache.org/job/maven-surefire/1626/)
          SUREFIRE-1198 Failsafe does not allow to configure the jar file to use (tibor17: rev f1aea63320b66e635e0dc27e4f9ecd0e155099d9)

          • (add) maven-failsafe-plugin/src/test/java/org/apache/maven/plugin/failsafe/IntegrationTestMojoTest.java
          • (edit) maven-surefire-plugin/src/site/apt/examples/configuring-classpath.apt.vm
          • (edit) maven-failsafe-plugin/pom.xml
          • (edit) maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
          • (edit) maven-surefire-plugin/src/site/fml/faq.fml
          • (edit) pom.xml
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in Jenkins build maven-surefire #1626 (See https://builds.apache.org/job/maven-surefire/1626/ ) SUREFIRE-1198 Failsafe does not allow to configure the jar file to use (tibor17: rev f1aea63320b66e635e0dc27e4f9ecd0e155099d9) (add) maven-failsafe-plugin/src/test/java/org/apache/maven/plugin/failsafe/IntegrationTestMojoTest.java (edit) maven-surefire-plugin/src/site/apt/examples/configuring-classpath.apt.vm (edit) maven-failsafe-plugin/pom.xml (edit) maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java (edit) maven-surefire-plugin/src/site/fml/faq.fml (edit) pom.xml
          Hide
          pwebb Phillip Webb added a comment -

          Thanks Tibor Digana!! Exactly what I had in mind.

          Show
          pwebb Phillip Webb added a comment - Thanks Tibor Digana !! Exactly what I had in mind.
          Hide
          pwebb Phillip Webb added a comment - - edited

          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.

          Show
          pwebb Phillip Webb added a comment - - edited 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.
          Hide
          tibor17 Tibor Digana added a comment - - edited

          commit f1aea63320b66e635e0dc27e4f9ecd0e155099d9
          commit 432231e7e9d01b9ef109acd39176045e0b18e5a5

          Show
          tibor17 Tibor Digana added a comment - - edited commit f1aea63320b66e635e0dc27e4f9ecd0e155099d9 commit 432231e7e9d01b9ef109acd39176045e0b18e5a5
          Hide
          rfscholte Robert Scholte added a comment -

          In the short term ...

          There are no temporary solutions. If we introduce a parameter, it'll stay there until at least the next major version. I have good hope that this can be fixed with the custom classloader option, so let's fix it immediately correct.

          Show
          rfscholte Robert Scholte added a comment - In the short term ... There are no temporary solutions. If we introduce a parameter, it'll stay there until at least the next major version. I have good hope that this can be fixed with the custom classloader option, so let's fix it immediately correct.
          Hide
          tibor17 Tibor Digana added a comment -

          Phillip Webb
          I think here is the fundamental problem in Spring group using integration tests. 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. 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.

          Show
          tibor17 Tibor Digana added a comment - Phillip Webb I think here is the fundamental problem in Spring group using integration tests. 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. 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.
          Hide
          pwebb Phillip Webb added a comment -

          That would be an ideal solution. In the short term, if we could just tell the plugin to use the backed up jar rather than the repackaged one, then we should be good. Spring Boot effectively creates a backup of the original JAR before it repackages it, I imagine if we pointed failsafe at that backup JAR then everything would work as before.

          Show
          pwebb Phillip Webb added a comment - That would be an ideal solution. In the short term, if we could just tell the plugin to use the backed up jar rather than the repackaged one, then we should be good. Spring Boot effectively creates a backup of the original JAR before it repackages it, I imagine if we pointed failsafe at that backup JAR then everything would work as before.
          Hide
          tibor17 Tibor Digana added a comment -

          Phillip Webb
          A custom classloader is a good idea. I would propose the issue in 3.0 or 3.1.
          We want to let the users give a chance to "inject" the code to Surefire/Failsafe from outside without asking the committer.

          Show
          tibor17 Tibor Digana added a comment - Phillip Webb A custom classloader is a good idea. I would propose the issue in 3.0 or 3.1. We want to let the users give a chance to "inject" the code to Surefire/Failsafe from outside without asking the committer.
          Hide
          pwebb Phillip Webb added a comment -

          The javadoc for classesDirectory appears to suggest that it could be used to specify an alternative JAR file, but this is not the case when the project artifact is set:

              /**
               * The path representing project <em>JAR</em> file, if exists; Otherwise the directory containing generated
               * classes of the project being tested. This will be included after the test classes in the test classpath.
               */
              @Parameter( defaultValue = "${project.build.outputDirectory}" )
              private File classesDirectory;
          
          Show
          pwebb Phillip Webb added a comment - The javadoc for classesDirectory appears to suggest that it could be used to specify an alternative JAR file, but this is not the case when the project artifact is set: /** * The path representing project <em>JAR</em> file, if exists; Otherwise the directory containing generated * classes of the project being tested. This will be included after the test classes in the test classpath. */ @Parameter( defaultValue = "${project.build.outputDirectory}" ) private File classesDirectory;
          Hide
          pwebb Phillip Webb added a comment - - edited

          I spoke with Robert Scholte 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:

              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;
              }
          

          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).

          Show
          pwebb Phillip Webb added a comment - - edited I spoke with Robert Scholte 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: 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; } 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).
          Hide
          rfscholte Robert Scholte added a comment -

          Failsafe prefers to use the jar. If you bind it to an earlier phase when there's no jar, it'll use the folder with the test-classes. But then you should wonder why not using the maven-surefire-plugin instead?
          So I had a look at the Spring-Boot-Maven-Failsafe-Plugin-Issue-master project. It seems like you've decided to introduce a BOOT-INFO/classes, the META-INF/MANIFEST.MF has an entry to this folder.
          This made me aware that the plugin is actually still not good enough. In case of an executable jar ( i.e the Main-Class entry is specified) where the Class-Path is specified as well, it should use those entries. Spring Boot does something similar, but with own specified entries.
          So the fix should be to be able to map or redirect classes.

          Show
          rfscholte Robert Scholte added a comment - Failsafe prefers to use the jar. If you bind it to an earlier phase when there's no jar, it'll use the folder with the test-classes. But then you should wonder why not using the maven-surefire-plugin instead? So I had a look at the Spring-Boot-Maven-Failsafe-Plugin-Issue-master project. It seems like you've decided to introduce a BOOT-INFO/classes , the META-INF/MANIFEST.MF has an entry to this folder. This made me aware that the plugin is actually still not good enough. In case of an executable jar ( i.e the Main-Class entry is specified) where the Class-Path is specified as well, it should use those entries. Spring Boot does something similar, but with own specified entries. So the fix should be to be able to map or redirect classes.
          Hide
          snicoll Stephane Nicoll added a comment -

          I disagree. Builds have different requirements. This particular one makes it so that the jar that should be used for ITs is not the main artifact of the project. Since we're forced to use the jar, making it configurable doesn't sound insane to me.

          Show
          snicoll Stephane Nicoll added a comment - I disagree. Builds have different requirements. This particular one makes it so that the jar that should be used for ITs is not the main artifact of the project. Since we're forced to use the jar, making it configurable doesn't sound insane to me.
          Hide
          rfscholte Robert Scholte added a comment - - edited

          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.

          Show
          rfscholte Robert Scholte added a comment - - edited 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.
          Hide
          snicoll Stephane Nicoll added a comment - - edited

          I can see that this issue got closed but I don't see a way to configure the jar file to use.

          In a Spring Boot project, we repackage the main jar with the fat jar and we rename the original jar. In 1.4, we've improved the jar layout and, long story short, failsafe doesn't work at all for us.

          We have a couple of workaround but having the ability to configure the jar file of the project that is going to be used is fairly important for us. Users of the shade plugin should find this useful as well.

          See this issue

          Show
          snicoll Stephane Nicoll added a comment - - edited I can see that this issue got closed but I don't see a way to configure the jar file to use. In a Spring Boot project, we repackage the main jar with the fat jar and we rename the original jar. In 1.4, we've improved the jar layout and, long story short, failsafe doesn't work at all for us. We have a couple of workaround but having the ability to configure the jar file of the project that is going to be used is fairly important for us. Users of the shade plugin should find this useful as well. See this issue
          Hide
          tibor17 Tibor Digana added a comment -

          Conny Kreyßel
          I was too fast writing the comment. I saw my System.out logs after the timeout 290 seconds.
          This means the test hangs on WinXP before the test method starts, maybe in Spring Runner.
          Why this is related only to old OS?
          WDYT?

          Show
          tibor17 Tibor Digana added a comment - Conny Kreyßel I was too fast writing the comment. I saw my System.out logs after the timeout 290 seconds. This means the test hangs on WinXP before the test method starts, maybe in Spring Runner. Why this is related only to old OS? WDYT?
          Hide
          tibor17 Tibor Digana added a comment -

          Conny Kreyßel
          Started the build of your project on WinXP and there really seems to be a problem.
          The test started and timed out after 200 seconds. No idea why.
          But another thing is interesteing to me. I printed std/out but I do not see anything in the console.
          Most probably Stringboot overrides std/out when the test starts and the Surefire does not receive command TESTSET_FINISHED from std/in and therefore expects a new test class but there's only one. We are using std/in and out as communication channel between Maven process and Surefire forked JVM.
          I don't see these logs:

          	@Before
          	public void check() {
          		System.out.println("################# B:TIBOR ##############");
          		assertNotNull(ctrl);
          	}
          	
          	@After
          	public void after() {
          		System.out.println("################# A:TIBOR ##############");
          	}
          
          Show
          tibor17 Tibor Digana added a comment - Conny Kreyßel Started the build of your project on WinXP and there really seems to be a problem. The test started and timed out after 200 seconds. No idea why. But another thing is interesteing to me. I printed std/out but I do not see anything in the console. Most probably Stringboot overrides std/out when the test starts and the Surefire does not receive command TESTSET_FINISHED from std/in and therefore expects a new test class but there's only one. We are using std/in and out as communication channel between Maven process and Surefire forked JVM. I don't see these logs: @Before public void check() { System .out.println( "################# B:TIBOR ##############" ); assertNotNull(ctrl); } @After public void after() { System .out.println( "################# A:TIBOR ##############" ); }
          Hide
          tibor17 Tibor Digana added a comment -

          The project is successfully running with one IT on Win7 in both cases
          Surefire 2.18.1 and 2.19.
          I will try to run (mvn verify) on WinXP in the evening.

          On Thu, Nov 26, 2015 at 2:49 PM, Conny Kreyßel (JIRA) <jira@apache.org>

          Show
          tibor17 Tibor Digana added a comment - The project is successfully running with one IT on Win7 in both cases Surefire 2.18.1 and 2.19. I will try to run (mvn verify) on WinXP in the evening. On Thu, Nov 26, 2015 at 2:49 PM, Conny Kreyßel (JIRA) <jira@apache.org>
          Hide
          azgard Conny Kreyßel added a comment -

          Hello Tibor Digana,

          we are inverstigating the issue in the spring boot project. https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159916604.

          I can reproduce it now. If you have a good old windows 2003/xp maybe you can try my testset to reproduce the bug. https://github.com/kreyssel/spring-boot-failsafe-plugin-console-hang-test-set

          But it looks like not an failsafe-plugin bug.

          Show
          azgard Conny Kreyßel added a comment - Hello Tibor Digana , we are inverstigating the issue in the spring boot project. https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159916604 . I can reproduce it now. If you have a good old windows 2003/xp maybe you can try my testset to reproduce the bug. https://github.com/kreyssel/spring-boot-failsafe-plugin-console-hang-test-set But it looks like not an failsafe-plugin bug.
          Hide
          tibor17 Tibor Digana added a comment -

          Stephane Nicoll
          How you want to continue if you close this ticket?
          It is not fair if you close it without saying "I fixed it like this and this...".

          Show
          tibor17 Tibor Digana added a comment - Stephane Nicoll How you want to continue if you close this ticket? It is not fair if you close it without saying "I fixed it like this and this...".
          Hide
          rfscholte Robert Scholte added a comment -

          So you want to test with another jar then the one being uploaded/deployed? Sounds like an unnecessary hack to me. I suggest to attach a simple project exposing the problem so we all understand the problem.

          Show
          rfscholte Robert Scholte added a comment - So you want to test with another jar then the one being uploaded/deployed? Sounds like an unnecessary hack to me. I suggest to attach a simple project exposing the problem so we all understand the problem.
          Hide
          snicoll Stephane Nicoll added a comment -

          What do you mean? I confirm that if surefire allows to configure the jar to use we are happy.

          Show
          snicoll Stephane Nicoll added a comment - What do you mean? I confirm that if surefire allows to configure the jar to use we are happy.
          Hide
          tibor17 Tibor Digana added a comment -

          More than fixing this issue I would say we would need to have ClassLoader for war and ear due to currently only jar is supported in this feature. Maybe more archive types..

          Show
          tibor17 Tibor Digana added a comment - More than fixing this issue I would say we would need to have ClassLoader for war and ear due to currently only jar is supported in this feature. Maybe more archive types..
          Hide
          tibor17 Tibor Digana added a comment -

          Conny Kreyßel
          If you use assembly plugin, do you attach and override the artifact file with its default name? If you don't then two jars do not make sense since one of them is not testable.

          Show
          tibor17 Tibor Digana added a comment - Conny Kreyßel If you use assembly plugin, do you attach and override the artifact file with its default name? If you don't then two jars do not make sense since one of them is not testable.
          Hide
          rfscholte Robert Scholte added a comment -

          I still think that everyone wants/expects (or should expect) the distributable to be tested and I'm very willing to help solving related issues. So it seems like the plugin must also decide if should use the adjusted pom.xml, that would help, right?

          Show
          rfscholte Robert Scholte added a comment - I still think that everyone wants/expects (or should expect) the distributable to be tested and I'm very willing to help solving related issues. So it seems like the plugin must also decide if should use the adjusted pom.xml, that would help, right?
          Hide
          tibor17 Tibor Digana added a comment -

          Stephane Nicoll
          Is it now working for you?

          Show
          tibor17 Tibor Digana added a comment - Stephane Nicoll Is it now working for you?
          Hide
          snicoll Stephane Nicoll added a comment -

          Configuring the jar to use would work for us. I'll have a look.

          Show
          snicoll Stephane Nicoll added a comment - Configuring the jar to use would work for us. I'll have a look.
          Hide
          tibor17 Tibor Digana added a comment -

          You can open a pull-request on GitHub and add parameter artifactName for failsafe only.
          We already have such things in AbstractSurefireMojo.
          Notice that classes folder is taken anyway if non-jar achive is packaged. For instance WAR file.

          Show
          tibor17 Tibor Digana added a comment - You can open a pull-request on GitHub and add parameter artifactName for failsafe only. We already have such things in AbstractSurefireMojo. Notice that classes folder is taken anyway if non-jar achive is packaged. For instance WAR file.
          Hide
          azgard Conny Kreyßel added a comment -

          At first this sounds fully correct to me.

          But in second you ignore that some plugins reassemble the jar (shade-plugin or spring-boot-maven-plugin). That means in intergration tests is not the "original" jar attached and used, but the "repackaged" jar.

          If you use the repackaged jar in integration test, you have also the assigned dependencies artifacts in classpath. This is really a bad situation.

          Maybe the default should use the jar in intergration tests - but we should have a swicth to disable this and use target/classes instead.

          Show
          azgard Conny Kreyßel added a comment - At first this sounds fully correct to me. But in second you ignore that some plugins reassemble the jar (shade-plugin or spring-boot-maven-plugin). That means in intergration tests is not the "original" jar attached and used, but the "repackaged" jar. If you use the repackaged jar in integration test, you have also the assigned dependencies artifacts in classpath. This is really a bad situation. Maybe the default should use the jar in intergration tests - but we should have a swicth to disable this and use target/classes instead.
          Hide
          tibor17 Tibor Digana added a comment -

          Yes there was a reason. The Surefire fixed this as a bug in Version 2.19.
          Without it unit test and integration test would not make any difference.
          The life cycle:
          compile
          test
          package
          integration-test
          verify

          This means classes is tested in unit test
          The package is tested in the integration tests.

          May I close this issue?

          Show
          tibor17 Tibor Digana added a comment - Yes there was a reason. The Surefire fixed this as a bug in Version 2.19. Without it unit test and integration test would not make any difference. The life cycle: compile test package integration-test verify This means classes is tested in unit test The package is tested in the integration tests. May I close this issue?

            People

            • Assignee:
              tibor17 Tibor Digana
              Reporter:
              snicoll Stephane Nicoll
            • Votes:
              6 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development