did i write "make our code obsolete with new versions of java"? while i'm not generally opposed to /top posting/, this is exactly what /inline replying/ is for ;) just place your question under the unclear lines in the dialog below and everyone and me understands what you are referring too :)
..ede On 09.08.2020 20:38, Michaud Michael wrote: > Thanks for your detailed answer Ede, > > 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 ? > > Michaël > > > >> 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 >> > > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
