ams-tschoening
commented
4 years ago Finally found the problem, the tests really ignore reporting.properties:
protected String openOfficePath = System.getenv("YARG_OPEN_OFFICE_PATH");
protected String fontsDirectory = System.getenv("YARG_FONTS_DIRECTORY");
public AbstractFormatSpecificTest() {
if (StringUtils.isBlank(openOfficePath)) {
openOfficePath = "C:/Program Files (x86)/LibreOffice/program";
}
if (StringUtils.isBlank(fontsDirectory)) {
fontsDirectory = "C:/Windows/Fonts";
}
}Is that really necessary if reporting.properties seems to be available to the test? Especially with widespread usage of 64 Bit-software, I suggest at least adding another fallback for the 64 Bit-install dir of LibreOffice if the 32 Bit doesn't exist or something like that.
The following makes the test succeed now:
C:\Users\tschoening\Downloads\yarg\core>set YARG_OPEN_OFFICE_PATH=C:/Program Files/LibreOffice/program
C:\Users\tschoening\Downloads\yarg\core>gradlew build --stacktrace
Environment
Description of the bug or enhancement
I've simply cloned current master of the repo and ran
gradlew buildon the shell, which results in errors like the following:Looking at the XML files created for test results by Gradle, the root cause always is the following:
At first that made sense, because the path to LibreOffice is configured in reporting.properties and simply doesn't fit my setup:
The problem is that after changing that path to where I really have my LibreOffice installed, things still fail:
cuba.reporting.openoffice.path=C:/Program Files/LibreOffice/program
As can be seen by the path, I'm using a 64 Bit version of LO and installed it in the platform default directory. But nevertheless, the tests keep failing. So I debugged things with Process Monitor and recognized that my configured path seems to be ignored entirely. The above path NEVER shows up in the logs, only the following does ALWAYS:
Note the suffix
(x86), so for some reason YARG is looking for a 32 Bit version of LO. That makes me especially wondering because Gradle is executed using a 64 Bit Java es well and I don't know where in the process of trying to load LibreOffice anything 32 Bit-related could come into play.Additionally, that path doesn't seem to be configured anywhere. I've tried all other combinations of paths in the config file I can think of: Forward vs. backslashes, file-URLs, relative paths etc. and additionally added nonsense directories like
murksin the path, just to have something unique to search for. But none of my paths ormurkshave been found in the logs of ProcMon, so YARG simply doesn't seem to do anything with that. I always only find the path above, so it seems to be some kind of fallback, but couldn't find where it comes from.So, do you have any example of how a Windows-path to LibreOffice needs to look like?
Regarding your code, you are supporting loading LO on Windows in general, as you explicitly use a binary called
soffice.exein those cases.Where does that fallback come from?
I've already looked at who tries to load LO at all, but couldn't find that path there as well:
https://github.com/LibreOffice/core/blob/master/jurt/com/sun/star/lib/util/NativeLibraryLoader.java
Do I need to do more than to change the path in
reporting.properties?I already verified that my changed file is really copied as resource for the tests by Gradle, that the changed file is read during running the tests etc. All that can bee seen in ProcMon, I only can't see usage of any of my configured paths.
Thanks for your help!