Update jts and slf dependencies to latest version #794
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is a version clash between the versions of spatial4j used in the postgis adaptor and the ES5.5. To avoid jar hell, implement our own postgis to HTS converter instead of using the adaptor.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.