yup indenting is clearly broken in this reply, maybe better not reply inline with that client Mike ;).. ede
On 12.08.2020 09:17, Michaud Michael wrote: > Hi, > > >>> 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... > > Could we decide to norrow openjump-plus to extensions hosted by the project > only, and revide the idea of a plugin manager (could be a student project ?). > > > 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. > > We'll try to fix this bug before the definitive migration. > > 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. > > I also suggest markdown for the same reasons > > > >> - (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? > > It is good for me, > > >> 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. > > I this migration to github and jts 1.17 succeeds, it will be a major step in > the > evolution of the project, thanks for your effort, > > >> - 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. > > I would say let's be open from the start, but I like the following proposition > to have an openjump/openjump-test project first (or maybe > openjump/openjump-migration), the time to fix main problems before we create a > more official openjump/openjump (to avoid to send a bad image of a project > with > plenty of inconsistencies). > > >> - 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. > > It is OK for me (consider openjump-migration as an alternative to > openjump-test). Maybe we could also consider the name openjump2 to underline > the > potential compatibility problems users may encounter if they use external > plugins. We'll also have to decide about some conventions for projects of the > same organisation hosting extensions : I would suggest to always include the > word plugin (or extension) in th eproject name, except for special cases like > sextante if we clone the code in openjump/. > > >> - 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 > > and https://github.com/mukoki > > 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 > _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
