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

Reply via email to