Andy Jefferson

FWIW Oracle JDBC driver(s) are in Maven central. Change https://github.com/locationtech/jts/blob/master/pom.xml#L116 to be "com.oracle.database.jdbc", "ojdbc8" and version 12.2.0.1 Change https://github.com/locationtech/jts/blob/master/modules/io/ora/pom.xml#L40 to be "com.oracle.database.jdbc", "ojdbc8". Change https://github.com/locationtech/jts/blob/master/modules/io/ora/README.md to remove the lines about...

Why not present a valid testcase that demonstrates something? As per https://www.datanucleus.org/documentation/problem_reporting.html#jdo

See https://github.com/datanucleus/datanucleus-core/issues/483. Not currently supported by DataNucleus for JDO or JPA (or Jakarta persistence), largely due to the fact that in all of the years of using converters not one...

I wont be ripping out code just because some corner case has some issue. You could provide a PR that allows a field to be marked with some metadata extension...

FWIW Some JPA providers already provide support for such types, and their querying. http://www.datanucleus.org:15080/products/accessplatform_5_2/jpa/mapping.html#_geospatial_types http://www.datanucleus.org:15080/products/accessplatform_5_2/jpa/query.html#jpql_functions_geospatial OGC Simple Feature spec would provide a starting point for such a specification.

Define "add support". JPA is an API. What is your *proposed* API? What some proprietary implementation software (that doesn't implement JPA) uses is not of much relevance here.

`radians()` and `degrees()` are also in that trig category, for people doing geospatial.

You mean apart from anyone wanting to use LOCAL (i.e non JTA) transactions? So a very large amount of existing JPA code.

FWIW DataNucleus has never had such a requirement, since it uses bytecode enhancement and adds a default constructor (when not provided) to each entity.

You mean https://github.com/eclipse-ee4j/jpa-api/issues/108