New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standalone jar requires net connection even for local GeoPackage #102
Comments
Thank you for the hint! Alternatively, the properties.dtd could be copied to the source code repository so that the test suite will always use the local copy instead of the online resource. However, as far as I know, it was never a requirement that the test suite also runs offline. So, there might also be other resources being referenced remotely. |
By looking at the list of test suites https://cite.opengeospatial.org/teamengine/ the GeoPackage test is probably the only one that can be run offline. However, server administrators do not like to open holes into the firewall and they would appreciate if they knew the trick to run the GPKG tests locally. Of course they have another good option in the GDAL Python script https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/samples/validate_gpkg.py. |
Then, it might be a good idea to remove the only existing online resource and to replace it with a local resource. By that, the test suite can be executed offline without any problems. |
Following is my workaround: [2] I am unable to build test-suite normally with reference [2] in test-run-props.xml because JUnit test cases are getting failed with below exception:
The reason of above failure is loadXMLFrom method of Properties class in the following JUnit test class
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
I am able to build the test-suite by skipping JUnit test cases and executed successfully. |
@dstenger
|
Fixed with this PR #103. |
The standalone jar file cannot be used for testing a local GeoPackage with a default test-run-props.xml file if there is no network connection. The reason is this reference in the props file
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
Offline check succeeds by downloading the DTD into local file system and changing the reference
<!DOCTYPE properties SYSTEM "file:///C:/teamengine/properties.dtd">
As an enhancement I suggest to document this workaround if it is not reasonable to add a copy of properties.dtd into the jar file or to skip the DTD check.
The text was updated successfully, but these errors were encountered: