You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
markusschuh opened this issue
Sep 25, 2019
· 3 comments
Labels
bugSomething isn't workingjavarelated to Java code, the Java Virtual Machine and directly related tooling (OpenJDK, Adoptium)testrelated to testing and QAwindowsspecific for Microsoft Windows OS
As a developer, I want to generate my own package including execution of included tests so that I can rely on a behavior of the software being compliant to the realized tests.
Actual behavior
A mvn package runs into test failures due to use of different conventions for path names during com.devonfw.tools.ide.configurator.ConfiguratorTest
Steps to reproduce (bug) / Use Case of feature request (enhancement)
Use windows 10 as build environment
use mvn 3.6.1
git clone ...
cd ide
mvn clean package
This results in errors as listed at end of issue.
Related/Dependent Issues
Comments/Hints:
As a workaround I can skip the tests. ( -Dmaven.test.skip=true)
As far as I understand the ConfiguratorTest code, this mismatch originates from the following difference:
The expecting value is generated from the Java code using the value as read from
private static final String DEVON_IDE_HOME = new File("").getAbsolutePath();
The compared value is generated by maven via expansion of the falling variable from the template for settings.json: ${client.env.home}
The first one generates - on windows - pathname using a single back slash, the second pathname (by maven) using double back slashes- valid in context, where back slash is an escape string. If there were some "compare canonical pathname" instead of a string compare, both would match. Currently they do not - on Windows only.
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.devonfw.tools.ide.configurator.ConfiguratorTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.312 sec <<< FAILURE!
testConfigurator(com.devonfw.tools.ide.configurator.ConfiguratorTest) Time elapsed: 0.24 sec <<< FAILURE!
java.lang.AssertionError:
File:
<C:\Users\auser\AppData\Local\Temp\.test.workspace\2019-09-25T11_30_14.044Z\json\settings.json>
read with charset <windows-1252> does not have the expected content:
Changed content at line 3:
expecting:
[" "java.home": "C:\work\devonfw-ide-test\configurator/software/java","]
but was:
[" "java.home": "C:\\work\\devonfw-ide-test\\configurator/software/java","]
Changed content at line 5:
expecting:
[" "bar": "C:\work\devonfw-ide-test\configurator/bar","]
but was:
[" "bar": "C:\\work\\devonfw-ide-test\\configurator/bar","]
Changed content at line 9:
expecting:
[" "C:\work\devonfw-ide-test\configurator""]
but was:
[" "C:\\work\\devonfw-ide-test\\configurator""]
Changed content at line 11:
expecting:
[" "foo": "C:\work\devonfw-ide-test\configurator/foo""]
but was:
[" "foo": "C:\\work\\devonfw-ide-test\\configurator/foo""]
at com.devonfw.tools.ide.configurator.ConfiguratorTest.testConfigurator(ConfiguratorTest.java:67)
...
The text was updated successfully, but these errors were encountered:
markusschuh
added
bug
Something isn't working
windows
specific for Microsoft Windows OS
test
related to testing and QA
java
related to Java code, the Java Virtual Machine and directly related tooling (OpenJDK, Adoptium)
labels
Sep 25, 2019
Lovely, @markusschuh thanks for the feedback. As I switched to MacOS and the CI runs on linux, I got a black spot for windows here. Will fix that after the release is complete as it is "only" an internal issue.
bugSomething isn't workingjavarelated to Java code, the Java Virtual Machine and directly related tooling (OpenJDK, Adoptium)testrelated to testing and QAwindowsspecific for Microsoft Windows OS
Expected behavior
As a developer, I want to generate my own package including execution of included tests so that I can rely on a behavior of the software being compliant to the realized tests.
Actual behavior
A
mvn package
runs into test failures due to use of different conventions for path names during com.devonfw.tools.ide.configurator.ConfiguratorTestSteps to reproduce (bug) / Use Case of feature request (enhancement)
mvn 3.6.1
git clone ...
cd ide
mvn clean package
This results in errors as listed at end of issue.
Related/Dependent Issues
Comments/Hints:
As a workaround I can skip the tests. (
-Dmaven.test.skip=true
)As far as I understand the ConfiguratorTest code, this mismatch originates from the following difference:
${client.env.home}
The first one generates - on windows - pathname using a single back slash, the second pathname (by maven) using double back slashes- valid in context, where back slash is an escape string. If there were some "compare canonical pathname" instead of a string compare, both would match. Currently they do not - on Windows only.
Affected version:
Windows 10 (1903)
An except of the output:
The text was updated successfully, but these errors were encountered: