Hi all,
Here are the different steps I made to try updating JTS to at least
1.15, the last one being 1.17.
The first thing I did was to install OpenJUMP (core / trunk) via SVN in
my IDE.
I realised that two Maven repositories are outdated in the
configuration, Central Maven 2
(http://central.maven.org/maven2) and Cambridge Maven 2
(https://maven.ch.cam.ac.uk/m2repo/).
The first one could be replaced by the kind of new Maven Central
repository, used by JTS:
<repository>
<id>Maven Central group</id>
<name>Maven Central group Repository</name>
<url>https://mvnrepository.com/artifact/</url>
</repository>
By adding this last one, it would mean that the OpenJUMP Maven
repositories aren't totally
internally dependent, because otherwise they rely mostly on:
http://jump-pilot.sourceforge.net/repository/
Even if it is sufficient in a certain extent, I encountered some
problems this morning when
I tried to import the Maven dependencies, having a joyful "Failed to
transfer [...] Error code
429, Too Many Requests". I imagine that some other services are slightly
more permissive.
Then I checked which OJ lib dependencies rely on JTS and it seems that
there is only deegree 2,
without considering here the plethora of extensions/plugins. This is
quite a good news because
if the deegree dependency is updated to its latest version (3.x.x),
which relies on JTS 1.15,
then, theoretically, only the import statements and a few other
com.vividsolutions directly used in the code
need to be modified.
It was therefore time to remove the current OJ JTS dependencies in the
Maven configuration
and to replace them with:
<dependency>
<groupId>org.locationtech.jts</groupId>
<artifactId>jts-core</artifactId>
<version>1.17.0</version>
</dependency>
<dependency>
<groupId>org.locationtech.jts</groupId>
<artifactId>jts-io</artifactId>
<version>1.17.0</version>
<type>pom</type>
</dependency>
Note that the second dependency has a pom type. Therefore, by default,
it didn't import
the jts-io related code, based on the current Maven configuration. This
JTS IO pom
only refers to some modules, including the one (common) containing the
GeoJSON related code
(reader, writer, etc.) used in OpenJUMP. See:
- (code) https://github.com/locationtech/jts/tree/master/modules/io/common
-
(pom)https://repo1.maven.org/maven2/org/locationtech/jts/jts-io/1.17.0/jts-io-1.17.0.pom
It was time to replace com.vividsolutions.jts. by org.locationtech.jts.
Using Eclipse as an IDE,
it was a straightforward move. A quick CTRL + H did the trick in a
matter of seconds.
In terms of results, it's pretty good:
- it worked globally well,
- the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic
due to the jts-io
pom type only, but once imported, this part of the code will be
functional again,
- some classes have been deprecated, removed, or simply moved in the new
JTS versions,
such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory.
New interfaces
have been created in JTS. It shouldn't be too complex to find a solution
or a workaround,
At that stage, most of the errors I had, were related to deegree. I
tried to import
deegree-core 3 using (note the pom type again):
<dependency>
<groupId>org.deegree</groupId>
<artifactId>deegree-core</artifactId>
<version>3.4.13</version>
<type>pom</type>
</dependency>
and I added this Maven repository:
<repository>
<id>deegree artifacts</id>
<name>deegree artifacts Repository</name>
<url>http://repo.deegree.org/content/repositories/releases/</url>
</repository>
Same problem than with JTS io, it doesn't import anything as it is a
parent pom linking
to some modules:
https://github.com/deegree/deegree3/tree/master/deegree-core
At that point, I started experimenting a bit with:
<dependencyManagement>
<dependencies>
<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
</dependency>
</dependencies>
</dependencyManagement>
rather than the classic:
<dependencies>
<dependency>
<groupId></groupId>
<artifactId></artifactId>
</dependency>
</dependencies>
without much success. I also tried to use the import scope
(<scope>import</scope>)
with the pom type, but as they can only be managed inside
<dependencyManagement>,
which is basically used in parent poms, it didn't help much, except if
the project is reconfigured.
I'm now reading some documentations about Maven and the recent changes
to see how
I can tackle this "pom type" problem without the need to import all of
the submodules
manually.
Another aspect of the deegree 3 dependency is that deegree-core relies
on a certain
number of common OJ dependencies. Here are the ones I identified:
- log4j / log4j (same version in both projects: 1.2.17) -- it would be
good to upgrade
to log4j 2 because there is a security problem in v1 and it isn't
maintained anymore
(see http://logging.apache.org/log4j/1.2/)
- org.slf4j / slf4j-api (deegree 1.7.13 vs OJ 1.7.25),
- org.slf4j / slf4j-log4j12 (deegree 1.7.13 vs OJ 1.7.25),
- org.locationtech.jts / jts-core (deegree 1.7.13 vs OJ 1.17 potentially
but 1.15 woud probably
be OK for the time being),
- xerces / xercesImpl (deegree 2.12.0 vs OJ 2.11.0),
- org.postgresql / postgresql (deegree 42.2.8 vs OJ 9.4.1208.jre6),
- org.apache.xmlgraphics / batik-awt-util (deegree 1.7 vs OJ 1.13), just
updated on the OJ
side a couple of days ago,
- same with org.apache.xmlgraphics / batik-dom,
- junit / junit (same version in both projects: 1.12),
- commons-codec / commons-codec (deegree 1.7 vs OJ 1.14),
- commons-io / commons-io (deegree 2.4 vs OJ 2.6),
- org.apache.commons / commons-lang3 (deegree 3.7 vs OJ 3.10),
- it.geosolutions.imageio-ext / imageio-ext-utilities (deegree 1.1.9 vs
OJ 1.1.16),
- it.geosolutions.imageio-ext / imageio-ext-tiff (deegree 1.1.9 vs OJ
1.1.13).
Once these problems of imports are solved, the JTS update should be
relatively
straightforward, and some work will probably be needed to update the code
based on deegree. I tried to update one of my plugins, it took me seconds
to do it, and I know that it would be exactly the same for the others,
just by
replacing com.vividsolutions.jts by org.locationtech.jts.
It generally should be relatively simple to update all the
extensions/plugins if they
don't rely on a dependency itself depending on JTS, like deegree for
example.
Finally, I share this link to an interesting deegree wiki page i found
(Java 11 support):
https://github.com/deegree/deegree3/wiki/Java-SE-11-Support
That's all for now.
Ede, or anyone, if you know the solution to these pom type dependencies,
thanks to
let me know.
Best,
Eric
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
