Not sure I get everything about the pom's problem, but I agree with all your proposition concerning OpenJUMP evolution.
One point which is not clear to me is what exactly will make our code obsolete with new versions of java ? Seems that at the moment, we can write java 8 code and compile it and run it with java 11 or more isn't it ?
envoyé : 9 août 2020 à 17:40
de : edgar.sol...@web.de
à : jump-pilot-devel@lists.sourceforge.net
objet : [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments
hey Eric,
welcome to the team! see my answers below
On 07.08.2020 20:55, Eric wrote:
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/
yeah, that's kind of a backup in case repos disappear which as you correctly determined happened since the last clean up (ages ago;)
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.
planned to move it to the current snapshot build machine at some point, as it holds the latest and most current dependencies of course. but never needed to, so here we are.
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.
which is the main obstacle. the only clean solution i see is to branch out a new OJ 2.x that initially will break compatibility to all external plugins. that's the bad news.
the good news is that this forces us to retouch pretty much all of them and during this effort we might eventually come up with a working plugin manager after all.
>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.
yeah, probably not. deegree2 is afaics used primarily or exclusively for the WFS extension and i remember checking out deegree3 as a drop in for deegree2 but failing miserably. that's why i stuck with deegree2 happy to have at least a working WFS extension for the time being.
but again, we can remove WFS from core for OJ 2.x and come up with a working extension later (if at all).
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,
that corresponds to my findings when trying to find a solution to the package renaming dilemma jts created in 2018. we talked about it on the ml but didn't find a solution
https://sourceforge.net/p/jump-pilot/mailman/jump-pilot-devel/thread/CA%2BALWNw%3DBfuQGjNLuOPgxU%2BBz7tcB5FeytomPVqFe9M5Sbh1hQ%40mail.gmail.com/#msg36283823
or
https://sourceforge.net/p/jump-pilot/mailman/search/?q=%22jts+1.15%22&limit=250&page=0&sort=posted_date%20desc
- 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,
how do you figure? com.vividsolutions.jump.io.geojson was written by myself from scratch utilizing google's json-simple . it holds no dependency apart from the jts geometry code. maybe myself placing it in this package has mislead you ;)
- 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,
agreed
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):
SNIP
</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.
as stated above. let's skip deegree3 but rather remove WFS for the time being and focus on JTS 1.15+ instead.
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).
mostly deegree3 issues that disappear if deegree3 is not needed
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.
sure. problem is not the port but gathering all plugin sources, setting up build env, porting and releasing the new modification for each and everyone. on the other hand, there is no alternative since locationtech forced our hand ;)
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
pretty much sums up the challenges we face as well. thanks for the link!
That's all for now.
Ede, or anyone, if you know the solution to these pom type dependencies, thanks to
let me know.
my maven-fu pretty much is compiled in the OJ pom. never needed it before or setting up the snapshot/release profiles. so you are on your own there. had to figure out some Ant for some finetuning but that's it. but it's pretty well documented, so we will get it into shape if something has to be changed.
going forward i'd suggest you (Eric)
1. work with the stable OJ 1.15 check out
2. remove WFS, here is the adding commit from 2014
https://sourceforge.net/p/jump-pilot/code/4219/
essentially it is the package 'de.latlon.deejump.wfs'
3. fixup a running port to JTS 1.15+
if that worked out you may holler and we can decide how to proceed. i could imagine
1. doing a "final" OJ 1.16 release only updated on critical issues
2. announcing and moving development focus over to OJ 2.x
3. branch OJ 2.x dev from the OJ 1.16 and apply the changes researched by Eric
3. extension fixup, extension fixup, ...
bonusbonusbonus
b1. maybe even finally porting the svn repo to git (to attract more comitters and make it easier to apply contributions), what's important to me here is to keep our commit history so we can still retrace changes after years and find out why they were done this way by the commit messages or by whom to ask them
b2. tackling java's module system jigsaw, as classpath based loading looks like to become a thing of the past
so far, so hot ..ede
ps. "how hard can it be?" :) - https://dilbert.com/strip/2020-08-07
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
