Re: [JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[Giuseppe Aruta]

Hi MIchael,
all the file I used, including jml files, are located here:
https://sourceforge.net/projects/opensit/files/Test%20file/Export%20to%20SVG/
Peppe

Il giorno mer 12 ago 2020 alle ore 19:59 michael michaud via
Jump-pilot-devel  ha scritto:

> I could open a project saved with 1.15 with r6370 and viceversa. My
> project contained a few vectors, and a geotif imported as an image and
> imported a second time as a sextante image.
> On the other hand, I get some problems if csv data is included in the
> project due to a breaking change I did. Not sure I can fix the bug about
> saving a csv in the project without breaking, but I'll have a deaper look.
> Before, I'd like to have more precision about your or Peppe test. What kind
> of datasources did they include ? csv/wkt ? Could you share the jmp files ?
> --
>
> * [bugs:#496]  OpenJUMP
> 1.15 freezes on loading project files from differing versions*
>
> *Status:* open
> *Created:* Tue Aug 11, 2020 10:35 AM UTC by ede
> *Last Updated:* Tue Aug 11, 2020 10:35 AM UTC
> *Owner:* nobody
>
> as described by Peppe on the mailing list
> "
> *On loading project files saved with different versions of OpenJUMP*.
> There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
> saving/loading project files.
> a) OpenJUMP 1.5 freezes on loading project files saved at least with
> OpenJUMP 6363 and 6370
> The console (I use Linux) doesn't show any warning.
> b) OpenJUMP 6363 and 6370 cannot load project files saved at least with
> OpenJUMP 1.5 .
> The console doesn't show any warning.
> c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
> versa
> "
> --
>
> Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net
> is subscribed to https://sourceforge.net/p/jump-pilot/bugs/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> ___
> 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

[JPP-Devel] [jump-pilot:bugs] #496 OpenJUMP 1.15 freezes on loading project files from differing versions

[michael michaud via Jump-pilot-devel]

I could open a project saved with 1.15 with r6370 and viceversa. My project 
contained a few vectors, and a geotif imported as an image and imported a 
second time as a sextante image.
On the other hand, I get some problems if csv data is included in the project 
due to a breaking change I did. Not sure I can fix the bug about saving a csv 
in the project without breaking, but I'll have a deaper look. Before, I'd like 
to have more precision about your or Peppe test. What kind of datasources did 
they include ? csv/wkt ? Could you share the jmp files ?


---

** [bugs:#496] OpenJUMP 1.15 freezes on loading project files from differing 
versions**

**Status:** open
**Created:** Tue Aug 11, 2020 10:35 AM UTC by ede
**Last Updated:** Tue Aug 11, 2020 10:35 AM UTC
**Owner:** nobody


as described by Peppe on the mailing list
"
*On loading project files saved with different versions of OpenJUMP*.
There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
saving/loading project files.
   a) OpenJUMP 1.5 freezes on loading project files saved at least with
OpenJUMP 6363 and 6370
  The console (I use Linux) doesn't show any warning.
   b) OpenJUMP 6363 and 6370  cannot load project files saved at least with
OpenJUMP 1.5 .
The console doesn't show any warning.
  c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
versa
"


---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[edgar . soldin]

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 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Eric]

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 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Giuseppe Aruta]

*>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, toavoid any confusion.*

Since Sextante java libraries have the potentiality to be extended to many
other gis projects (the original list was quite large: geotools, Openjump,
GvSig, Kosmo only to talk about gis which share the same Sextante libraries
with no modifications)
- in case we fork Sextante libraries in order to work with newer JTS
- in case that GvSig CE folks won't/cannot take care if the project
- in case that everyone of us agree

I will suggest to add to the former list also
- Sextante-test (or Sextante) to leave the door open to any other external
contributions. I know at least a couple of developer  in Italy who have
interest in raster analysis in java but are not focused specifically on
Openjump. They may be interested to partecipate to the project.
One is Alberto Bertazza who contributed on  raster framework in Openjump
and he is the developer of OpenKlem hydrologic raster analysis toolbox
plugin, Integrated in Openjump plus.
Kindly regards
Peppe

Il mer 12 ago 2020, 09:17 Michaud Michael  ha
scritto:

> 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, 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[edgar . soldin]

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/
> - 

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

[Michaud Michael]

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 branchhttps://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