I would love to see this work go ahead! Anything we can do to support you? As for plans this is an open community please make a proposal - and then you are part of the planning :)
On Fri, Mar 13, 2020 at 11:03 AM Daniel Cruver <ddcru...@gmail.com> wrote: > 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 > -- -- Jody Garnett
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
