In GeoTools 20.x, the units library was updated from JSR 271 to JSR 363 Units (Units 1.0). Which was a great improvement because I was encountering classpath issues before I upgrade my projects to using a newer version of GeoTools. I am using JSR 385 in my project but adding GeoTools still causes additional ServiceProvider to be available that are incompatible and cause the process to close if I access them. This can be avoided but another problem is that including GeoTools on my projects also adds incompatible unit and systems to the classpath and causes confusion.
JSR 363: systems.uom:systems-common-java8:0.7.2 JSR 385: systems:uom:systems-common:2.0.0 tech.units:indriya:2.x Basically if the packages start with "tec.uom" are from the older libraries but they now exist in "javax.measure" and "tech.units". I have done most of the grunt work to rename the packages but the custom GeoTools UnitFormats and SexagesimalConverter require more work. Good new I think some of the workarounds that had to be done in GeoTools related to https://github.com/unitsofmeasurement/uom-se/issues/201 are no longer necessary in the unitofmeasure libraries and reference implementation of JSR 385.
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
