Skip to content
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

Closed
jratike80 opened this issue Apr 1, 2020 · 6 comments · Fixed by #103
Closed

Standalone jar requires net connection even for local GeoPackage #102

jratike80 opened this issue Apr 1, 2020 · 6 comments · Fixed by #103
Assignees
Projects
Milestone

Comments

@jratike80
Copy link

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.

@dstenger dstenger added this to To do in CITE via automation Apr 6, 2020
@dstenger
Copy link
Contributor

dstenger commented Apr 6, 2020

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.
What do you think about that approach?

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.

@jratike80
Copy link
Author

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.

@dstenger
Copy link
Contributor

dstenger commented Apr 7, 2020

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.

@dstenger dstenger moved this from To do to In progress in CITE Apr 7, 2020
@keshavnangare
Copy link

Following is my workaround:
[1] <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">

[2] <!DOCTYPE properties SYSTEM "C:\properties.dtd">

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:

org.opengis.cite.gpkg12.VerifyTestNGController
cleanTestRun(org.opengis.cite.gpkg12.VerifyTestNGController)  Time elapsed: 0.013 sec  <<< ERROR!
java.util.InvalidPropertiesFormatException: org.xml.sax.SAXException: Invalid system identifier: file:///C:/properties.dtd
        at org.opengis.cite.gpkg12.VerifyTestNGController.loadDefaultTestRunProperties(VerifyTestNGController.java:50)
Caused by: org.xml.sax.SAXException: Invalid system identifier: file:///C:/properties.dtd
        at org.opengis.cite.gpkg12.VerifyTestNGController.loadDefaultTestRunProperties(VerifyTestNGController.java:50)

The reason of above failure is loadXMLFrom method of Properties class in the following JUnit test class

this.testRunProps.loadFromXML(getClass().getResourceAsStream("/test-run-props.xml"));
which expects the XML document must have the following DOCTYPE declaration:
<!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.

@keshavnangare
Copy link

@dstenger
Following are the fixes of the issue:

  1. Check whether we can use relative path to avoid the use of an absolute path:

    We can use the relative path to point local properties.dtd file and able to run the test. We can see the below snippet which will use the dtd file from the test project resource directory.

    <!DOCTYPE root-name SYSTEM "./org/opengis/cite/gpkg12/dtd/properties.dtd">

  2. Fix Junit tests case:
    I have added fix for the Junit test case to load the properties file from the test-run-props.xml file.

@keshavnangare
Copy link

Fixed with this PR #103.

@keshavnangare keshavnangare moved this from In progress to To verify in CITE Apr 16, 2020
@dstenger dstenger assigned dstenger and lgoltz and unassigned keshavnangare Apr 22, 2020
CITE automation moved this from To verify to Done Mar 5, 2021
@dstenger dstenger added this to the 1.1 milestone Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
CITE
  
Done
4 participants