JBehave
  1. JBehave
  2. JBEHAVE-538

Wrong encoding in reports running from JUnit (maven failsafe or surefire plugin, not dedicated jebhave maven plugin) on Windows

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.4.2, 3.4.3, 3.4.4, 3.4.5
    • Fix Version/s: None
    • Component/s: Core
    • Environment:
      Windows, for example with cp1250 encoding (Poland/PL)
    • Number of attachments :
      1

      Description

      With -Dfile.encoding=UTF-8 FreeMaker still is using and rendering html report with cp1250 encoding, output log from maven install command:

      ...
      (stories/sample.story)
      Scenario: Przykładowy scenariusz numer 1 śżł
      Given Given cośtamźłś (PENDING)
      When ByłśżźńŚĄ (PENDING)
      Then Gżegżłką (PENDING)
      @Given("Given co\u0139\u203Atam\u0139\u015F\u0139\u201A\u0102\u0142\u0139\u203A")
      ...
      Generating reports view to 'e:\Jenkins\jobs\jbehave-encoding-test\workspace\target\jbehave' using formats '[console, txt, html, stats]' and view properties '

      Unknown macro:

      {defaultFormats=stats, decorateNonHtml=true, viewDirectory=view, decorated=ftl/jbehave-report-decorated.ftl, reports=ftl/jbehave-reports-with-totals.ftl, maps=ftl/jbehave-maps.ftl, navigator=ftl/jbehave-navigator.ftl, views=ftl/jbehave-views.ftl, nonDecorated=ftl/jbehave-report-non-decorated.ftl}

      '
      [encoding-test] DEBUG Could not find template in cache, creating new one; id=[ftl/jbehave-report-decorated.ftl[pl_PL,Cp1250,parsed] ]
      [encoding-test] DEBUG Compiling FreeMarker template ftl/jbehave-report-decorated.ftl[pl_PL,Cp1250,parsed] from jar:file:/C:/.m2/repository/org/jbehave/jbehave-core/3.4.4/jbehave-core-3.4.4.jar!/ftl/jbehave-report-decorated.ftl
      [encoding-test] DEBUG Could not find template in cache, creating new one; id=[ftl/sh.ftl[pl_PL,Cp1250,parsed] ]

        Activity

        Hide
        Mauro Talevi added a comment -

        Why do you say that encoding issues only occur when not running via the maven plugin?

        Seems to me that problem is independent of the way they are run.

        Show
        Mauro Talevi added a comment - Why do you say that encoding issues only occur when not running via the maven plugin? Seems to me that problem is independent of the way they are run.
        Hide
        Mariusz Smykula added a comment -

        Yes, you are correct. This example has always wrong encoding. I have other project which is wrong only with JUnit...

        Show
        Mariusz Smykula added a comment - Yes, you are correct. This example has always wrong encoding. I have other project which is wrong only with JUnit...
        Hide
        Jean Helou added a comment - - edited

        The problem still exists on 3.5 and 3.6-beta-2

        Show
        Jean Helou added a comment - - edited The problem still exists on 3.5 and 3.6-beta-2
        Hide
        Mauro Talevi added a comment -

        Hi, this problem is rather difficult to debug without having a native polish build.

        Given that it only occurs when using a non-JBehave plugin, one guess could be due to the encoding in the resources being copied. You could try setting the encoding to UTF-8 there as well:

        http://maven.apache.org/plugins/maven-resources-plugin/examples/encoding.html

        Else, we'd need to establish where (at which stage of the build) the encoding goes wrong.

        Show
        Mauro Talevi added a comment - Hi, this problem is rather difficult to debug without having a native polish build. Given that it only occurs when using a non-JBehave plugin, one guess could be due to the encoding in the resources being copied. You could try setting the encoding to UTF-8 there as well: http://maven.apache.org/plugins/maven-resources-plugin/examples/encoding.html Else, we'd need to establish where (at which stage of the build) the encoding goes wrong.
        Hide
        Jean Helou added a comment -

        Hi there,
        I am ashamed to admit it was a false alarm. while the console reporting spits out the \u encoded characters for the pending steps, the step actually is matched, the problem came from the reporter configuration which didn't play nice with maven paths.

        Show
        Jean Helou added a comment - Hi there, I am ashamed to admit it was a false alarm. while the console reporting spits out the \u encoded characters for the pending steps, the step actually is matched, the problem came from the reporter configuration which didn't play nice with maven paths.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mariusz Smykula
          • Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: