Details

    • Type: Bug Bug
    • Status: Reopened Reopened (View Workflow)
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.3.0.Beta3
    • Fix Version/s: LATER
    • Component/s: build, upstream
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      If I run JBT tycho build locally for trunk, for example:
      mvn clean install -fae -e -P default -f cdi/tests/pom.xml
      and there is some test failures then I don't see any stacktrace in console. Just a text message from the JUnit test assert.
      -Dsurefire.useFile=false does not help.
      But I see the stacktrace in <target>/surefire-reports

      In Beta1 branch it works fine.

      I don't see stacktrace in console output in Hudson either but I'm not sure it's a problem there.
      For example https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job/jbosstools-3.3_trunk.component--cdi/lastCompletedBuild/console
      But for local builds it's very useful to see the full stacktrace in console.

        Issue Links

          Activity

          Hide
          Mickael Istria
          added a comment -

          You can see a stacktrace for the failing test here: https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job/jbosstools-3.3_trunk.component--cdi/945/testReport/org.jboss.tools.cdi.core.test/CDICoreAllTests/initializationError/
          Is this what you are looking for?
          Also, have you looked into the .log file?

          Show
          Mickael Istria
          added a comment - You can see a stacktrace for the failing test here: https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job/jbosstools-3.3_trunk.component--cdi/945/testReport/org.jboss.tools.cdi.core.test/CDICoreAllTests/initializationError/ Is this what you are looking for? Also, have you looked into the .log file?
          Hide
          Alexey Kazakov
          added a comment -

          Yes, I can find a stacktrace in Hudson in result page and I even can find this stacktrace in <plugin>/<target>/surefire-reports folder (see the description of this issue) but I can't see it in console output when I running the build locally.
          It's very easy to reproduce:
          1. Open org.jboss.tools.cdi.core.test.CDIImagesTest
          2. Add the following method

          public void testFoo() {
              fail("You should see a stacktrace here");
          }
          

          3. mvn clean install -fae -e -P default -f cdi/tests/org.jboss.tools.cdi.core.test/pom.xml
          4. There is no stacktrace for testFoo() in console output (that's the problem!). But you can find it in cdi/tests/org.jboss.tools.cdi.core.test/target/surefire-reports/*

          Show
          Alexey Kazakov
          added a comment - Yes, I can find a stacktrace in Hudson in result page and I even can find this stacktrace in <plugin>/<target>/surefire-reports folder (see the description of this issue) but I can't see it in console output when I running the build locally . It's very easy to reproduce: 1. Open org.jboss.tools.cdi.core.test.CDIImagesTest 2. Add the following method public void testFoo() { fail( "You should see a stacktrace here" ); } 3. mvn clean install -fae -e -P default -f cdi/tests/org.jboss.tools.cdi.core.test/pom.xml 4. There is no stacktrace for testFoo() in console output ( that's the problem! ). But you can find it in cdi/tests/org.jboss.tools.cdi.core.test/target/surefire-reports/*
          Hide
          Mickael Istria
          added a comment -

          Ok,

          I guess surefire-plugin was updated to not show stack trance in console in order to prevent from huge outputs. There might be an option for it, I'll investigate. If you find the magic option before me, please share it.

          Show
          Mickael Istria
          added a comment - Ok, I guess surefire-plugin was updated to not show stack trance in console in order to prevent from huge outputs. There might be an option for it, I'll investigate. If you find the magic option before me, please share it.
          Hide
          Max Rydahl Andersen
          added a comment -

          googling says "mvn -Dsurefire.useFile=false test"

          Show
          Max Rydahl Andersen
          added a comment - googling says "mvn -Dsurefire.useFile=false test"
          Hide
          Mickael Istria
          added a comment -

          there may be an issue in tycho-surefire-plugin that does not honor this property any more.

          Show
          Mickael Istria
          added a comment - there may be an issue in tycho-surefire-plugin that does not honor this property any more.
          Hide
          Max Rydahl Andersen
          added a comment -

          on plane right now and missing dependencies so can't test this but in tychosurefire code is looks like useFile is hardcoded to true but there is a "redirectTestOutputToFile" that might be worth trying.

          definitely should try get this fixed in tycho if still the case.

          Show
          Max Rydahl Andersen
          added a comment - on plane right now and missing dependencies so can't test this but in tychosurefire code is looks like useFile is hardcoded to true but there is a "redirectTestOutputToFile" that might be worth trying. definitely should try get this fixed in tycho if still the case.
          Hide
          Max Rydahl Andersen
          added a comment -

          relevant comment in tycho git repo:

          " 367778 TestMojo: don't redirect console to file by default

          Revert to old default behaviour which prints console
          logs from tests to System.out by default.
          Make test output redirection to file configurable
          using TestMojo parameter "redirectTestOutputToFile",
          same as maven-surefire-plugin, see [1]

          [1] http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#redirectTestOutputT"

          Show
          Max Rydahl Andersen
          added a comment - relevant comment in tycho git repo: " 367778 TestMojo: don't redirect console to file by default Revert to old default behaviour which prints console logs from tests to System.out by default. Make test output redirection to file configurable using TestMojo parameter "redirectTestOutputToFile", same as maven-surefire-plugin, see [1] [1] http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#redirectTestOutputT "
          Hide
          Mickael Istria
          added a comment -

          Alexey,

          When I look at this build: https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job/jbosstools-3.3_trunk.component--cdi/1097/consoleFull
          I see the following

          -------------------------------------------------------
           T E S T S
          -------------------------------------------------------
          Running org.jboss.tools.cdi.core.test.CDICoreAllTests
          Exception in thread "Thread-6" java.lang.NullPointerException
          	at org.jboss.tools.common.java.ParametedType.findParameter(ParametedType.java:302)
          	at org.jboss.tools.common.java.ParametedTypeFactory.getParametedType(ParametedTypeFactory.java:85)
          	at org.jboss.tools.common.java.ParametedType.buildInheritance(ParametedType.java:183)
          	at org.jboss.tools.common.java.ParametedType.getInheritedTypes(ParametedType.java:229)
          	at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:319)
          	at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321)
          	at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321)
          	at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321)
          	at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321)
          	at org.jboss.tools.common.java.ParametedType.getAllTypes(ParametedType.java:307)
          	at org.jboss.tools.cdi.core.test.TypeTest$R.run(TypeTest.java:76)
          	at java.lang.Thread.run(Thread.java:662)
          Running Update class path of kb project RemoveJarTest
          Running Update class path of kb project RemoveJarTest
          2
          void addEntry(Object) [in ClassFragmentLogger [in ClassFragmentLogger.java [in org.jboss.jsr299.tck.tests.jbt.validation.observers [in JavaSource [in tck]]]]]
          void observeObject(Object) [in EventTypeFamilyObserver [in EventTypeFamilyObserver.java [in org.jboss.jsr299.tck.tests.event.eventTypes [in JavaSource [in tck]]]]]
          Tests run: 432, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 288.383 sec <<< FAILURE!
          
          Results :
          
          Failed tests:   testType(org.jboss.tools.cdi.core.test.TypeTest): expected:<11> but was:<0>
          
          Tests run: 432, Failures: 1, Errors: 0, Skipped: 0
          

          Does this output mean this issue is fixed or do you expect more?

          Show
          Mickael Istria
          added a comment - Alexey, When I look at this build: https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job/jbosstools-3.3_trunk.component--cdi/1097/consoleFull I see the following ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jboss.tools.cdi.core.test.CDICoreAllTests Exception in thread " Thread -6" java.lang.NullPointerException at org.jboss.tools.common.java.ParametedType.findParameter(ParametedType.java:302) at org.jboss.tools.common.java.ParametedTypeFactory.getParametedType(ParametedTypeFactory.java:85) at org.jboss.tools.common.java.ParametedType.buildInheritance(ParametedType.java:183) at org.jboss.tools.common.java.ParametedType.getInheritedTypes(ParametedType.java:229) at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:319) at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321) at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321) at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321) at org.jboss.tools.common.java.ParametedType.buildAllTypes(ParametedType.java:321) at org.jboss.tools.common.java.ParametedType.getAllTypes(ParametedType.java:307) at org.jboss.tools.cdi.core.test.TypeTest$R.run(TypeTest.java:76) at java.lang. Thread .run( Thread .java:662) Running Update class path of kb project RemoveJarTest Running Update class path of kb project RemoveJarTest 2 void addEntry( Object ) [in ClassFragmentLogger [in ClassFragmentLogger.java [in org.jboss.jsr299.tck.tests.jbt.validation.observers [in JavaSource [in tck]]]]] void observeObject( Object ) [in EventTypeFamilyObserver [in EventTypeFamilyObserver.java [in org.jboss.jsr299.tck.tests.event.eventTypes [in JavaSource [in tck]]]]] Tests run: 432, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 288.383 sec <<< FAILURE! Results : Failed tests: testType(org.jboss.tools.cdi.core.test.TypeTest): expected:<11> but was:<0> Tests run: 432, Failures: 1, Errors: 0, Skipped: 0 Does this output mean this issue is fixed or do you expect more?
          Hide
          Alexey Kazakov
          added a comment -

          I'm not sure.
          This is not an AssertionFailedError which is usually thrown by assert() or fail() in tests.
          Anyway I just ran our tests locally and still don't see the stacktrace in console. But maybe it works in Hudson?

          Show
          Alexey Kazakov
          added a comment - I'm not sure. This is not an AssertionFailedError which is usually thrown by assert() or fail() in tests. Anyway I just ran our tests locally and still don't see the stacktrace in console. But maybe it works in Hudson?
          Hide
          Viacheslav Kabanovich
          added a comment -

          Alexey, as you suggested, method ParametedType.findParameter is not thread safe. I have committed the fix.

          Show
          Viacheslav Kabanovich
          added a comment - Alexey, as you suggested, method ParametedType.findParameter is not thread safe. I have committed the fix.
          Show
          Mickael Istria
          added a comment - Highly related: http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02465.html https://bugs.eclipse.org/bugs/show_bug.cgi?id=378938
          Hide
          Mickael Istria
          added a comment -

          Marking it as "Won't fix" because we wont make efforts regarding that request. Stacks can be found in the surefire-reports files, as you can read in Maven log after a test failed.
          Logs can be found in target/work/data/.metadata/.log.

          Show
          Mickael Istria
          added a comment - Marking it as "Won't fix" because we wont make efforts regarding that request. Stacks can be found in the surefire-reports files, as you can read in Maven log after a test failed. Logs can be found in target/work/data/.metadata/.log.
          Hide
          Max Rydahl Andersen
          added a comment -

          I think this is one of the issues that makes development slower and slower since you have to either fall back to use eclipse directly or run surefire reports generation to actually get an overview of what stacktraces are problematic.

          for one stacktrace its "doable", but as soon as you are running with -fae (fail at end) you might get multiple ones and looking those up manually becomes a chore instead of an easy look at the console log for the root error.

          Alexey Kazakov, Martin Malina, Denis Golovin etc. do you find it okey to live with the current situation or shouldn't we make a push for making this happen ?

          Show
          Max Rydahl Andersen
          added a comment - I think this is one of the issues that makes development slower and slower since you have to either fall back to use eclipse directly or run surefire reports generation to actually get an overview of what stacktraces are problematic. for one stacktrace its "doable", but as soon as you are running with -fae (fail at end) you might get multiple ones and looking those up manually becomes a chore instead of an easy look at the console log for the root error. Alexey Kazakov , Martin Malina , Denis Golovin etc. do you find it okey to live with the current situation or shouldn't we make a push for making this happen ?
          Hide
          Jiri Peterka
          added a comment -

          When running mvn -X -e clean verify I can see a stacktrace of some failing tests in a console - at least some of them. This might be possibly dependent how test fails. Anyway any improvement is welcome here.

          Show
          Jiri Peterka
          added a comment - When running mvn -X -e clean verify I can see a stacktrace of some failing tests in a console - at least some of them. This might be possibly dependent how test fails. Anyway any improvement is welcome here.
          Hide
          Alexey Kazakov
          added a comment -

          Max Rydahl Andersen, I'm OK with the current situation.
          When you run a bunch of test plugins (an entire component for example) then the output is so long that you it's more convenient to see the particular surefire-report files rather than scrolling the console.
          When you run a single plugin it would be faster/easier to get stacktraces in console output. But we can go to the corresponding surefire-report files. Not a big deal.

          Show
          Alexey Kazakov
          added a comment - Max Rydahl Andersen , I'm OK with the current situation. When you run a bunch of test plugins (an entire component for example) then the output is so long that you it's more convenient to see the particular surefire-report files rather than scrolling the console. When you run a single plugin it would be faster/easier to get stacktraces in console output. But we can go to the corresponding surefire-report files. Not a big deal.

            People

            • Assignee:
              Mickael Istria
              Reporter:
              Alexey Kazakov
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: