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
