Hi Michael, Right in this moment I am writing an email to answer your previous email with more details about my tests on recompiling Sextante. In few minutes I will send it to you
Il giorno ven 19 mar 2021 alle ore 10:14 Michaud Michael < m.michael.mich...@orange.fr> ha scritto: > Hi Peppe, > > I found this mail dating from 2020, august 10th about Sextante migration. > > Can you tell me how far you have gone in your investigation/work about > migrating Sextante. It seems to be a difficult but important part of our > migration process. I'd like to upload all the necessary code in the new > openjump-gis/sextante-extension project so that we can work together on > this topic. > > Regards, > > Michaël > > *envoyé :* 10 août 2020 à 21:02 > *de :* Giuseppe Aruta <giuseppe.ar...@gmail.com> > *à :* eric.openj...@thefactory.io, OpenJump develop and use < > jump-pilot-devel@lists.sourceforge.net> > *objet :* Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments > > >>Less than a day of work should be required (if not less) to update all > the plugins which do not rely on a dependency which relies itself on JTS. > I'm going to test it, to see if it's the case. > > Possibly Sextante Will be a problem as we don't have the source code of > the project (it is available on GvSig CE svn repository). And Sextante.jar, > Sextante-gui.jar and Sextante-algorithms.jar partially rely on JTS. > I gave a look at the source code: the versione available on GvSig CE is a > bit different from the one embedded into Openjump: there are some > enhancements and few depencies to GvSig class: nothing serious as I tested > their version with Openjump and it works fine. Right now my tested version > of Openjump for raster analysis uses GvSig CE sextante. > > My idea is to download Sextante source code from GvSig CE and try to > recompile it with new JTS. And prepare some tests following Sextante > documentation and user's notes (Openjump with all raster tools is used in a > couple of courses at the University of Padua) . > I will also mail to GvSig CE folks. GVSIG CE (at least sextante) seems > not have activity since a couple of years. > Peppe > > > > > > Il lun 10 ago 2020, 15:52 Eric <eric.openj...@thefactory.io> ha scritto: > > Here is the list of all the SVN authors (and their number of > contributions) according to the logs: > beckerl 197 > bertazza 29 > bgudehus 6 > clark4444 6 > edso 1305 > elnico 54 > eric.lemesre 4 > infinityedge 2 > jammerhund 47 > javamap 10 > jratike80 22 > kdneufeld 2 > lreeder 1 > ma15569 602 > mentaer 465 > michaudm 1619 > paul_d_austin 38 > s-l-teichmann 1 > stranger 87 > > If you want to keep track of them in the possible future Git repository, a > conversion file needs to be created, for example (with one author per line): > michaudm = Michael Michaud <em...@test.com> <em...@test.com> > > We should maybe do this outside this mailing list to avoid creating a list > of public email addresses. > > For info, I easily managed to locally create a Git repository containing > the 1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your > different answers to move to the next step. > > Best, > Eric > > On 10/08/2020 14:42, Eric wrote: > > Hi Ede, > > Thanks for your welcome and for your answers. See my inline replies for > some of them (I deleted the other parts). > > On 09/08/2020 16:40, edgar.sol...@web.de wrote: > > hey Eric, > > welcome to the team! see my answers below > > On 07.08.2020 20:55, Eric wrote: > > 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. > > > Less than a day of work should be required (if not less) to update all the > plugins which do not rely on a dependency which relies itself on JTS. I'm > going to test it, to see if it's the case. > I tried with my plugins and I just needed a couple of seconds to do it. > > 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 seems to be a good compromise for the time being as the migration from > deegree-core 2 to deegree-core 3 isn't straightforward. > > - 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 > > > Have a look at the GeoJsonReader class for example, and the method > MapGeoJsonGeometryReader (see the comment), or the > GeoJSONFeatureCollectionWrapper class. You will see that there is a > dependency to JTS io. > It doesn't mean that there is a real dependency in the way it works, but > JTS io (now jts-io-common which includes the GeoJSON code) is needed for > the code to compile. > > - 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 > > > After the JTS upgrade, only two classes require some changes: > - org.openjump.core.ui.plugin.tools.ReducePointsISAPlugIn -- relatively > easy to solve, > - another written by Michaël, com.vividsolutions.jump.geom.MakeValidOp. > For this one, a few JTS constructors have evolved. The problem is linked to > the 4th dimension, dimension that can't be retrieved any more with a simple > getter. One temporary solution could consist in the creation of a class > which extends the current JTS one with an additional getter / setter for > the dimension. > > 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 > > I answer this point later in the discussion, including a possible > migration to Git. > > 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. > > OK. Thanks. > > 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 > > > My plan was nearly identical. Here it is: > - Using OJ 1.15 core including trunk, tags and branches, > - Migrating the code to Git based on something like this: > https://www.atlassian.com/git/tutorials/svn-to-git-prepping-your-team-migration. > It includes the preservation of the commit history (critical point) > including the authors of these commits (more details here -- authors.txt > --: https://www.atlassian.com/git/tutorials/migrating-prepare) -- I don't > know yet if it's possible to link the authors to new Git accounts (this > would be great). Note that this migration automatically recreates the tags > and branches, > - Creating a repository with this code on Github or Gitlab (see below for > an open discussion about it), > - At this stage, I would drop the WFS part of the code, including the > package 'de.latlon.deejump.wfs' as Ede mentioned but also the 'org.deegree' > one. I would also drop the deegree-core dependency in the pom.xml, > - Removing the two Maven repositories mentioned in a previous message, > adding the new one as mentioned too, > - Updating JTS to a 1.15+ version, ideally the 1.17 as it doesn't change > much between 1.15 and 1.17, both for JTS and JTS io common for the GeoJSON > part. Replacing all com.vividsolutions.jts by org.locationtech.jts and > working on a workaround for both ReducePointsISAPlugIn and MakeValidOp > classes. Push the results once it compiles / works, > - Creating a small document containing all the different undertaken steps. > - (Bonus) Upgrading the Log4j dependency to v2 and therefore removing the > current security issue in link with it. > > > Open discussion: > - Preliminary remark: I don't want at any point of this process, acting as > if I was taking this project under my umbrella/name. As I wrote to Michaël, > you're the drivers/guardians of this project, I'm just a passenger. > Therefore, just let me know what you prefer, the way you want to do things, > and I'll act accordingly. Thanks, > - The idea is to create a temporary Git project/repository as Ede > mentioned too. There are two main platforms for that, GitHub and GitLab. > Let me know which one you prefer, knowing that it is possible to have both > solutions, working only on one, with a mirroring for the other using this > solution (this includes automated push/pull): > https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html > - Would you prefer an open or a private repository? Why do I consider the > private option here? To avoid any confusion with the current OpenJUMP > repository on sourceforge and to avoid some possible premature forks, > - Where do I need to create this project? In my personal account, or an > OpenJUMP organisation is created, and the project takes place there (I > would personally prefer this option, in link with my preliminary remark)? > If an OpenJUMP organisation is created, do you want to create it yourself > or is it OK if I create it? > - Have you already got some GitHub/GitLab accounts that I could use to let > you access the project as administrators? > > > So if I sum up the questions: > - Github vs Gitlab, > - Open vs private repository (just for the period of this test), > - Where? Personal account vs OpenJUMP organisation, > - GitHub/GitLab accounts for administration. > > About Ede's b2 point: I tested OJ with a Java 11 environment both with > OpenJDK and an Oracle one. It works with both, as far as I tested it. I > didn't try with Java 14. I prefer using OpenJDK as there is no commercial > restriction with it. > > ps. "how hard can it be?" - https://dilbert.com/strip/2020-08-07 > > > > Thanks a lot for your views on that Ede. > > Please let me know what you prefer and I'll act accordingly. > > Best, > Eric > > > _______________________________________________ > 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
