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
