Update to newer Version of GeoTools to support Java 11

[fgdrf]

Currently 19.4 is bundled in uDig and GeoTools supports Java 11 beginning with version 21.0

This issue is about to upgrade to GeoTools 21++ independently from Java-Version.

[fgdrf]

see GeoTools upgrade guide how to handle Units package change to si.uom and for Geometry library to org.locationtech.jts (from com.vividsolutions.jts)

[nprigour]

Since the proposed update seems quite a huge task I would suggest to resolve as many pending issues/PRs as possible before going with this.

[fgdrf]

Since the proposed update seems quite a huge task I would suggest to resolve as many pending issues/PRs as possible before going with this.

Fair point! We started to work on this during an Eclipse Hackathon session early this month.

However, maybe we can collaborate on this and test whole applications. Right now its not in a state to submit somthing we can work on but stay tuned ;)

[fgdrf]

org.joda.time dependency is not used by GeoTools, its a dependency from uDig define in pom-libs.xml:

		<dependency>
			<groupId>joda-time</groupId>
			<artifactId>joda-time</artifactId>
			<version>1.6</version>
		</dependency>

as stated on mailinglist few years ago it makes sense to seperated this dependeny and re-bundle it as Eclipse smarthome project did.

Following modules importing org.joda.time classes:

• org.locationtech.udig.catalog.kml
• org.locationtech.udig.jconsole
• org.locationtech.udig.omsbox
• org.locationtech.udig.project (in ViewportModel and RenderPackage API)
• org.locationtech.udig.tools.jgrass

[fgdrf]

Following modules importing org.joda.time classes:

• org.locationtech.udig.catalog.kml
• org.locationtech.udig.jconsole
• org.locationtech.udig.omsbox
• org.locationtech.udig.project (in ViewportModel and RenderPackage API)
• org.locationtech.udig.tools.jgrass

Since all listed modules are (indirectly) dependent from org.locationtech.udig.project it might make sense to bundle joda-time within that module and export packages from there.

Opinions?

[egouge]

What about removing this dependency entirely and updating to the "new-ish" java.time api?

[fgdrf]

What about removing this dependency entirely and updating to the "new-ish" java.time api?

Good point, this would required to re-generate classes from Model I guess. Can you help here?

Maybe it makes sense to make it in two steps:

1. seperate joda-time dependency into a new bundle (rather then packging it into uidg.project bundle)

2. move on to new java.time api and re-generate classes from EMF model

[egouge]

I've never regenerated the model, so I don't know if I could help, but I could try!

FYI - I am using a modified branch of uDig that I upgraded to geotools 21.1 and removed the joda time package. I only use a very small number of the udig plugins, and only updated those. I didn't regenerate the emf model - I just updated the data types, which so far it seems to be working for my limited use case.

[fgdrf]

Good to hear uDig runs with GeoTools 21.x. I assume jgrass and jconsole stuff isn't bundled into your application..
However we can handle it.

I just saw a transitive dependency from gt-netcdf (19.4) module in libs-bundle which can be provided using import package in MF file of org.locationtech.udig.libs (and upgrade to newer version)

[INFO] +- org.geotools:gt-netcdf:jar:19.4:compile
[INFO] |  +- edu.ucar:cdm:jar:4.6.6:compile
[INFO] |  |  +- edu.ucar:udunits:jar:4.6.6:runtime
[INFO] |  |  +- edu.ucar:httpservices:jar:4.6.6:runtime
[INFO] |  |  |  +- org.apache.httpcomponents:httpclient:jar:4.5.1:runtime
[INFO] |  |  |  \- org.apache.httpcomponents:httpmime:jar:4.5.1:runtime
[INFO] |  |  +- org.apache.httpcomponents:httpcore:jar:4.4.4:runtime
[INFO] |  |  +- joda-time:joda-time:jar:2.8.1:runtime

I've to check if netcdf 21.x still has this dependency ..

[fgdrf]

GeoTools 22.0 has been released which includes an update of EPSG database. Thanks to @jodygarnett for this info since it might fix #242

[nprigour]

Hi @fgdrf ,

I see that you have included this isssue to 2.1.0 release milestone. However compared to the previous release (2.0.0) we have already carried out a significant update from geotools 14.x to 19.x. Therefore IMHO and given the size of the expected refactoring effort, it would be more prudent to have a stable (or at least and interim) release with the 19.4 version of geotools and then delve into the "refactoring hell" that support of geotools 22.x will require.