looks unmaintained with last commit being from 2017-05-24 https://sourceforge.net/p/gvsigce/code/HEAD/tree/trunk/sextante/
..ede On 11.08.2020 08:31, Giuseppe Aruta wrote: > 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 > <mailto: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 <http://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 >>> <mailto: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> <mailto: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 >>>> <mailto: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 >>> <mailto: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
