Hi Eric - This is the link to GvSIG CE SVN of Sextante: https://svn.code.sf.net/p/gvsigce/code/trunk/sextante
- Regarding OJ binding we use. You will find the source code in OpenJUMP Plugin SVN. It has been modified during these years in order to a better integration wof both Software (OpnJUMP and Sextante) a quick list of main changes: - better recognize of nodata values - activation of modeler, and other sextante tool - integration of output results interface to OpenJUMP in order to have all output not vector or raster (diagrams, tables, html, etc) - from OpenJUMP e from Sextante into an unique space (see classes in org.openjump.sextante.gui.additionalResults from OJ SVN) - As far as I remember the version of Sextante we ship is "1.0". Actual GvSIG version is named "1.0.0" Best regards Peppe Il giorno lun 10 ago 2020 alle ore 22:16 Eric <eric.openj...@thefactory.io> ha scritto: > I also found the sources for the 0.6 version here, directly exported from > code.google.com/p/sextante: https://github.com/danieldupre/sextante > The OpenJUMP bindings are included. > > Víctor Olaya could also be contacted to help if needed: > https://github.com/volaya > > Finally, I found a version 1.0 of Sextante in the 52°North project but > only the compiled code is accessible (in their own Maven repository). It > seems to be a Maven refactoring based on the 0.6 version: > https://github.com/52North/WPS/tree/dev/52n-wps-sextante > > Eric > > On 10/08/2020 20:44, Eric wrote: > > Thanks. > > Is it different from this repository: > - https://joinup.ec.europa.eu/svn/sextante/soft/sextante_lib/ > - (OpenJUMP bindings) > https://joinup.ec.europa.eu/svn/sextante/soft/bindings/openjump/ > > I tried to find the source code of GvSig CE but I failed. Could you please > send us a link to their SVN repository? Thanks. > > Eric > > On 10/08/2020 20:02, Giuseppe Aruta wrote: > > >>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
