Expose GeoDataFrame geometry dependencies to consumers#2005
Conversation
|
So, do we need all dependencies to be |
|
@copilot answer to the latest question from @Jolanrensen |
Only a handful need |
There was a problem hiding this comment.
Pull request overview
This PR fixes downstream Gradle compilation failures caused by dataframe-geo exposing JTS/GeoTools types in its public API while keeping the corresponding dependencies non-transitive (implementation). By moving those dependencies to api, consumers can compile against public geometry/geospatial types (e.g., org.locationtech.jts.geom.Geometry) without manually adding extra dependencies.
Changes:
- Switched GeoTools module dependencies from
implementationtoapi. - Switched JAI and JTS dependencies from
implementationtoapito ensure transitive availability for consumers.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Ok @copilot, after your self-review on API vs. implementation, please make some new commits and move some dependencies back. |
Done in |
|
I don't trust copilot on this. It made different dependencies
|
dataframe-geoexposed JTS and GeoTools types in its public API while declaring their dependencies asimplementation, causing[MISSING_DEPENDENCY_CLASS]errors for downstream Gradle projects.implementationtoapi.org.locationtech.jts.geom.Geometrywithout manually adding transitive dependencies.