working mail addresses will be difficult to get for everyine and generally unnecessary as well. just need to keep the history and committer ids to enable retracing changes in the future as well.
..ede On 10.08.2020 15:52, Eric wrote: > 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> > > 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
