Hi Eric Open discussion:
*>>- 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 <https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html>* No preference for me. As I can see GitLab offers a free Continuous Integration which could be useful in a project like Openjump where Night builds are very frequent and, sometime, preferred by users more than the stable realize. *>>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,* I am not afraid if forks: it is a part of the surviving life of Jump. Right now Openjump is the only (as far as I know) survivor of Jump family. Anyhow I agree to a private repository only for the time of migration. And to make it public when we are sure that everything is working. - >>*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?* Openjump organization seems in continuity with the "philosophy" of the project. - >>*Have you already got some GitHub/GitLab accounts that I could use to let you access the project as administrators?* Not yet. I will open one in these days Peppe Il mar 11 ago 2020, 23:59 Eric <eric.openj...@thefactory.io> ha scritto: > Hi Ede, > > Thanks. I let the licencing issue aside as it seems to be resolved. See > my inline answers. > > On 11/08/2020 12:01, edgar.sol...@web.de wrote: > > tl;dr let's wait how the licensing issue (other email) turns out, apart > from that my answers below. > > > > On 10.08.2020 15: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. > > again. we don't have sources for all extensions in OJ Plus at hand or > setup to build at all. the challenge won't be the modding but the finding > and setting up plugin repos. > > I wasn't aware of this situation. All of a sudden, it seems to be > another challenge to migrate all the plugins... > > >>>> 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. > > agreed > > So I'll do that. > > >>>> - 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. > > good catch ;). right for creating Geoms from Maps JTS is used. forgot > about it. > > > > depending on the size of the import we might just copy the code from the > latest LGPL'd JTS or actually implement it ourselfs. ok, just checked > > https://github.com/locationtech/jts/releases/tag/1.17.0 > > jts-io-common-1.17.0.jar is just 15kB big so let's just keep the JTS > code. > > OK. > > >>>> - 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. > > sounds reasonable > > I'll then use this temporary solution. > > >>>> 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, > > there is a critical bug opening JMP project files which should be fixed > before we branch > > https://sourceforge.net/p/jump-pilot/bugs/496/ > > The idea here is to test the migration based on the OJ 1.15 release, to > know if it works and to see what could be improved during the final > migration. Nothing definitive. > > >> - 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. > > can be placed under docs/ in the repo > > As it's just a test, I thought that it could be good to keep it at the > root of the project, to allow a quick access. But if you prefer the docs > folder, I'll do it. > > Any format preference for this document? MD (Markdown) or RST > (reStructuredText)? Both are easily and directly readable from GitHub / > GitLab. I would probably suggest Markdown as it's slightly more common > and because we don't need the specificities of RST at this stage. > > >> - (Bonus) Upgrading the Log4j dependency to v2 and therefore removing > the current security issue in link with it. > > the reason that this was not done before is that some extensions were > compiled against it. as we are doing a clean break anyway i am not opposed > anymore. note: we have our "own" com.vividsolutions.jump.workbench.Logger > which is supposed to be the one stop solution for extension but internally > uses Log4J again. > > What I could do is, once JTS and the OJ code have been updated on the > master branch, to create another branch (based on the latter) to test a > Log4j update. What do you think? > > >> 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, > > thanks for contributing your time and effort! > > It's the least I can do after having used OJ for years. > > >> - 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 > > good to know. > > > >> - 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, > > we can easily add notes in the Readme pointing out the provisional > status of the OJ2 development. anyone wanting to fork still i have no > objections. after all it's not called open source for nothing ;) > > I'm waiting some other answers (from Peppe, Michaël, etc.) on that. If > none, I'll create a public repository. > > >> - 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? > > is "organisation" something like a team definition provided by > github/-lab ? > > Yes indeed. The term "organisation" is used by GitHub, and the terms > "group" and "subgroup" are used by GitLab: > - (GitHub) https://github.blog/2010-06-29-introducing-organizations/ > - (GitLab) https://docs.gitlab.com/ee/user/group/ > > An Organisation and a Group can contain several projects. It is quite > useful to easily link related projects. In the OJ context, one project > could be the OJ core, another one the default plugins, another the PLUS > plugins, etc. (or a different project for each plugin). > > Even if there is no real convention (afaik), organisations and groups > are often written in lower case with hyphens if necessary. For example: > - https://github.com/geotools/geotools > - https://github.com/locationtech/jts > > So for OpenJUMP I would suggest: > - openjump for the organisation / group, > - openjump for the main code, > - openjump-test for the temporary project we are talking about here, to > avoid any confusion. > > Let me know if you agree with this naming, and what to do, i.e. do you > want that I create this organisation / group or if you prefer doing it? > If you let me do it, I'll transfer immediately the ownership to all of you. > > >> - Have you already got some GitHub/GitLab accounts that I could use to > let you access the project as administrators? > > sure, https://github.com/edeso > > Thanks. > > >> 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. > > for preliminary testing on your side feel free to use whichever service > private/public shouldn't matter. for an eventual fork actually used as > basis for OJ2 development let's still talk about details. i'm (and probably > the others as well) not very familiar with setting up projects on either > github/-lab. > > If you're happy with a public one, it's probably better as we'll benefit > from better CI/CD tools. This should allow us to test the current OJ > builds, maybe to try different ones if necessary or at least to adapt > the current process within the context of GitHub/GitLab, as it appeared > to be a crucial aspect of the migration. > > This is really a test to see the feasibility (Git migration, JTS update, > OJ code update consequently, builds, plugins update, etc.) -- based on > the current OJ 1.15 release for now --, to document the different > undertaken steps in order to be able to reproduce them if needed and > when decided (for example to create OJ 2.x). > > >> 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. > >> > > agreed, we should strive to be openjdk compatible exactly because of the > restrictions that Oracle introduced on their java runtime. > > > >> Please let me know what you prefer and I'll act accordingly. > > up to you, risking that licensing might not be possible, you may work > out a proper conversion routine to a git service of your choice. using your > documentation we may then using OJ 1.15.1/1.16 as a base for OJ2 > development when/if the licensing is cleared up. > > > > maybe you can shed a light which you think would be the better choice > (github/-lab)? > > As a lot of other GIS related projects are already on GitHub, such as > JTS, GeoTools, GeoNode, etc., it seems that it would be a good place to > start with. Some projects like GEOS are directly hosted by OSGeo, then > mirrored on GitHub and GitLab, and thus benefiting from different CI/CD > tools. > > > Quick summary about the current options: > - choice of GitHub, > - creation of an openjump (lowercase) organisation in GitHub -- > question: who does this creation? if you let me do it, I transfer the > co-ownership to Ede, Michaël and Peppe (others?) as soon as I know their > individual GitHub accounts (already known for Ede). This organisation > has a link to the OpenJUMP website, to the OJ mailing list > (jump-pilot-devel@lists.sourceforge.net) > - creation of a openjump-test (lowercase) repository within this > organisation, > - this repository is a public one, > - migration of the OJ core (1.15 release -- revision 6242) containing > the trunk, tags and branches to the openjump-test repository -- being > aware that there is a critical bug reported here: > https://sourceforge.net/p/jump-pilot/bugs/496/, > - this migration uses <sfnetusername>@users.sourceforge.net for the > authors (i.e. all committers), and keeps the history since the first > available SVN revision (using the logs, it seems to be the 859), > - update of JTS (version 1.17) including the update of related OJ code > (solving the two classes mentioned in my previous message), the update > of pom.xml, the removal of deegree-core 2 / deejump code (basically WFS > related code), the creation of a README.md or .rst to clearly state that > this a migration/update test and a link to the current releases / code, > the creation of a documentation / report about this migration at the > root of the repository named MIGRATION.md, > - later, creation of another branch to test if it's possible to use > Log4j v2. > > Ede, Michaël and Peppe, could you let me know if you agree or/and > disagree about one or several aspects of this list. > > Once all your answers are received and a compromised reached, I'll > proceed accordingly. > > Best, > Eric > > > > > so far.. thanks! ede > > > > > > _______________________________________________ > > 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
