openjump-gis ok for me too 2020-08-14 12:03 GMT+02:00, edgar.sol...@web.de <edgar.sol...@web.de>: > oj-devs > oj-developers > oj-team > or jump instead of oj > > so many possibilieits ..ede:)) > > On 14.08.2020 11:53, Giuseppe Aruta wrote: >> jump-pilot >> or >> openjump-pilot >> or >> openjump2 >> >> 2020-08-14 11:50 GMT+02:00, Eric <eric.openj...@thefactory.io>: >>> Hi, >>> >>> The GitHub support team answered me this morning, stating that the >>> ownership transfer of the 'openjump' username or organisation is not >>> possible at the moment: >>> >>>> While I'd love to help, I'm afraid we won't be able to release that >>>> username for you today as it's not dormant (not all activity on GitHub >>>> is public) or available for release under our name-squatting policy >>>> (https://docs.github.com/en/github/site-policy/github-username-policy). >>>> Sorry I don't have better news to share with you on this. >>>> >>>> Though it may not apply here, it's worth mentioning that we have a >>>> trademark policy that could allow you to obtain a username that's >>>> already been claimed. If the username you're interested in is a >>>> trademark you hold, I'd recommend taking a look at that policy for >>>> more information about potentially filing a violation report: >>>> >>>> https://docs.github.com/github/site-policy/github-trademark-policy >>> >>> I just created an organisation named 'openjump-gis' for the time being >>> (hyphens are allowed), according to the title of the openjump.org index >>> page and as it gives an idea of what the project is about. The following >>> options are also available at the moment: >>> - open-jump, >>> - openjumpgis >>> - openjump-project / openjumpproject >>> - oj-gis / ojgis >>> - jump-pilot / jumppilot >>> - openjump-pilot / openjumppilot >>> - geopenjump >>> >>> Note that openjump is available on GitLab for the moment, if you wish to >>> create a mirror repository there. >>> >>> It's always possible to rename an organisation later on (see >>> https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-an-organization). >>> This process automatically updates everything from link redirection to >>> commit attribution. >>> >>> I already added Ede (edeso) and Michaël (mukoki) as owners of this >>> organisation. >>> >>> I also just created an 'openjump-migration' repository as previously >>> discussed and I am now tuning the settings of both the organisation and >>> the repository. >>> >>> Feel free to modify the content / info / settings about these. >>> >>> I should be able to push a first working version for next Monday, maybe >>> before but as schools reopened on Wednesday here in Scotland (children >>> don't attend it on a daily basis during this first week), I can't >>> promise anything. >>> >>> Eric >>> >>> On 12/08/2020 13:38, edgar.sol...@web.de wrote: >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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
