[
https://issues.apache.org/jira/browse/CALCITE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637991#comment-17637991
]
Bertil Chapuis commented on CALCITE-5399:
-----------------------------------------
The main issue I encountered with GeoAPI was the package name clash with
GeoTools on org.opengis.geoapi and the resulting exceptions. Sadly, as a lot of
projects use GeoTools, this often prevented me from using the standard.
Migrating from GeoTools to SIS is also non trivial, as the jars cannot cohexist
in the same classpath. I suspect that some projects depending (transitively?)
on Calcite may encounter this issue. For instance, I think that Sedona depends
on Calcite through Flink and provides a non-free wrapper for GeoTools. As this
situation looks a bit stalled, I was wondering if a pragmatic way to make
progress would be to use a package named org.geoapi instead of
org.opengis.geoapi for the standard.
Regarding the present issue, the following change to the build.gradle.kts file
allows the compilation and te tests to pass.
{{- api("org.locationtech.jts.io:jts-io-common")}}
{{+ compileOnly("org.locationtech.proj4j:proj4j")}}
{{+ testImplementation("org.locationtech.proj4j:proj4j")}}
When Calcite is included in a project without proj4j, a call to ST_Transform
will throws a ClassNotFoundException. This seems to be confirmed by the fact
that, when the testImplementation dependency is removed, only the tests related
to ST_Transform are failing.
Would this be sufficient to comply with the requirements of the ASF?
> Proj4j license is not compatible with Apache
> --------------------------------------------
>
> Key: CALCITE-5399
> URL: https://issues.apache.org/jira/browse/CALCITE-5399
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.32.0
> Reporter: Bertil Chapuis
> Assignee: Bertil Chapuis
> Priority: Major
> Fix For: 1.33.0
>
>
> As explained by [~desruisseaux] in [1], despite being released with an Apache
> compatible license, Proj4j is a problematic dependency. The EPSG codes used
> by Proj4j come with restrictive terms of use [2] and we should find an
> alternative.
> [1] [https://lists.apache.org/thread/2g6j1jx7q5l1sx4mfp1w29obgnvrnvq5]
> [2] [https://epsg.org/terms-of-use.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
