Switch s2-geometry to google's 'official' version #14599
Conversation
…cessor configuration from versions.lock - it does not seem to be relevant to us.
github-project-automation
bot
moved this to Open
in OpenSearch Lucene & Core Performance Tracking
| @@ -28,7 +28,6 @@ allprojects { | |||
|
|
|||
| def testConfigurations = project.configurations.matching { | |||
| it.name in [ | |||
| "annotationProcessor", | |||
There was a problem hiding this comment.
I've removed annotation processor configuration from version lock computation. I don't think it's relevant to us what's used in annotation processors.
|
This requires pulling in guava, which in turn has a module-info in a multi-release jar location. ECJ fails on this due to this bug I filed 4 years ago: |
…va is on module path and error prone (annotation processor) uses it. If it's excluded from module classpath, it cannot be found and fails the build.
|
I've made it run and compile. It is surprisingly hairy because of modular classpaths, errorprone interactions and extra dependencies brought in. There is a single version of this s2 geometry library ever published. At this point I'm thinking we could just fold whatever is needed into this module (it is asl2) instead of importing the external jar... |
|
I like the idea of reducing the deps: not anything crazy, but just trying to keep the dep tree minimal. We frequently hear from users on decades-old versions on the ML, so it is less problems for end-users as well. |
|
I've already excluded what was possible. Anything more would require copying the code over and manual removal of dependencies (which shouldn't be too difficult). I'm at crossroads here. This guava dependency is going to be a problem, I can sense it. |
This isn't complete. There are some extra dependencies I'm not sure are needed. But overall, the transition seems to be simple. Not that the "new" library from Google is that well maintained (there is only one version published).