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

          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: