Gradle's dependency management makes it a bit simpler to work with the very old ElasticSearch version.
JTS is a bit tricky because it has been moved around quite a bit from 'com.vividsolutions.jts.jts' to ´com.vividsolutions.jts.jts-core' to 'org.locationtech.jts.jts-core'. ES still depends on the version from vividsolutions. This in itself is not an issue, we could simply include both version s of the library. The actual blocker turns out to be 'org.locationtech.spatial4j ´. It is used in the ES library, where it is expected to return vividsolution geometries. And it is used in the postgis-jdbc-jtsparser, where after the update a locationtech geometry is expected. The solution is to get rid of postgis-jdbc-jtsparser and implement our own parsing of PostGIS geometries.
Gradle's dependency management makes it a bit simpler to work with the very old ElasticSearch version.
JTS is a bit tricky because it has been moved around quite a bit from 'com.vividsolutions.jts.jts' to ´com.vividsolutions.jts.jts-core' to 'org.locationtech.jts.jts-core'. ES still depends on the version from vividsolutions. This in itself is not an issue, we could simply include both version s of the library. The actual blocker turns out to be 'org.locationtech.spatial4j ´. It is used in the ES library, where it is expected to return vividsolution geometries. And it is used in the postgis-jdbc-jtsparser, where after the update a locationtech geometry is expected. The solution is to get rid of postgis-jdbc-jtsparser and implement our own parsing of PostGIS geometries.