no worries. i'm pretty sure we are not fixed on that name. for years we have been known as /jump-pilot/ (anybody know why?) and it worked as well. how about you work with a private repo in the mean time and we'll deal with name and organisation when we are ready to branch which is not going to be tomorrow ;)
..ede On 12.08.2020 13:19, Eric wrote: > Hi all, > > Thanks to all of you. > > According to your answers, I'm in the process of creating a GitHub > organisation named 'openjump', containing a public repository named > 'openjump-migration'. The current problem is that someone created an account > or an organisation with this name last April (https://github.com/openjump), > but with no activity since then. I just contacted the GitHub support team to > see if it was possible to have a transfer of ownership for this name -- so, > of course, with the agreement of the current owner), as it isn't allowed to > directly contact the owner for obvious reasons. > > Apart from that, everything is ready. > > Eric > > On 12/08/2020 10:06, edgar.sol...@web.de wrote: >> 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 > > > > _______________________________________________ > 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
