Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Migrated to another ITS
    • 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.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            mickael_istria 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 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
            akazakov 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
            akazakov 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 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 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
            maxandersen Max Rydahl Andersen added a comment -

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

            Show
            maxandersen Max Rydahl Andersen added a comment - googling says "mvn -Dsurefire.useFile=false test"
            Hide
            mickael_istria 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 Mickael Istria added a comment - there may be an issue in tycho-surefire-plugin that does not honor this property any more.
            Hide
            maxandersen 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
            maxandersen 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
            maxandersen 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
            maxandersen 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 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 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
            akazakov 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
            akazakov 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
            scabanovich Viacheslav Kabanovich added a comment -

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

            Show
            scabanovich Viacheslav Kabanovich added a comment - Alexey, as you suggested, method ParametedType.findParameter is not thread safe. I have committed the fix.
            Show
            mickael_istria 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 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 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
            maxandersen 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
            maxandersen 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
            jpeterka 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
            jpeterka 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
            akazakov 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
            akazakov 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.
            Hide
            mickael_istria Mickael Istria added a comment -
            Show
            mickael_istria Mickael Istria added a comment - Issue tracked on Tycho side: https://bugs.eclipse.org/bugs/show_bug.cgi?id=378938

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development