CRSdefinitions test fails due to dependency issue (again)

[ajanett]

NSG_SpatialReferenceSystemsTests.java, Line 230: call to CRS.parseWKT( srsDef ); is failing 'again'. What is actually happening is not a failure of parseWKT itself, but since the ReferencingObjectFactory cannot be cast, the failure ends up as a general exception. This revision of gpkg12-nsg includes a simple output statement that the table could not be examined due to a processing exception rather than just throwing a java exception as it used to.

The complexities related to these dependencies and parseWKT need an in-depth look, preferably by those that developed this in the first place.

See also issue #12 (closed) as these are likely related.

[dstenger]

Thank you for reporting. We will do further investigation.

[lgoltz]

The complexities related to these dependencies and parseWKT need an in-depth look, preferably by those that developed this in the first place.

As far as I know he is not available any longer.
It would be great if you could take a deeper look into it. Otherwise we need some more information how to reproduce the failure.

[ajanett]

I did spend several days on this some time ago, found it to be complex with java dependencies and cross dependency issues going on and I did kind of wonder why this was developed in this way. I tried several different things with no luck. I don't have any time left this week to work on this particular effort but perhaps next week.

Have you been able to see this at all? With all of the work on the spatial reference systems area I was hoping this might also have been addressed.

[lgoltz]

Have you been able to see this at all?

No, I've not seen this yet.
How do you test? I'm using the docker environment (https://github.com/opengeospatial/teamengine-docker/) with the current master.

[ajanett]

Current master set to latest version (0.4), and TEAM Engine command line via script startup or Tomcat. I have then stepped through this code from the debugger.
I have installed the following test packages (all of them set to the latest master or the latest tagged version if one exists): 'ets-gpkg12','ets-gpkg12-nsg', 'ets-dgiwg', 'ets-dgiwg-core', 'ets-gml32', 'ets-kml22', 'etsowc10', 'ets-wcs20', 'ets-wfs20', 'ets-wfs20-dgiwg', 'ets-wfs20-dgiwg-nsg', 'ets-wfs20-nsg', 'ets-wms13', 'ets-wms13-dgiwg', 'ets-wms13-nsg', 'ets-wps10', 'ets-wmts10', 'ets-wmts10-nsg', 'ets-dgiwg'

[lgoltz]

Maybe you can try only with ets-gpkg12-nsg (and of course the required ets) to suspend a dependency conflict?

[ajanett]

This does appear to be a dependency conflict of some sort. When I set up TEAM Engine with the tests listed above, there is an issue. If I set up TEAM Engine with only ets-gpkg12-nsg and ets-gpkg12, then the problem does not appear. I'll try to investigate further as I am able to narrow down the ets that is impacting this.

[ajanett]

I believe I have identified the issue and am working on a fix for it. The problem is a conflict between the use of geotools and geotoolkit within the test suites. This particular ETS happens to reference geotools, Whereas gml32, which is a dependency of several ETS packages (including WFS), makes use of geotoolkit. This geopackage ETS should be changed to use geotoolkit so as to be consistent with the rest of the test suites.

See also, the ets-wfs20 issue opengeospatial/ets-wfs20#97

[dstenger]

@ajanett Is this issue solved by #45?