Hi,
On 19/01/2021 13:13, edgar.sol...@web.de wrote:
On 1/19/2021 9:19, Michaud Michael wrote:
Hi Jumpers
Thanks to Eric's guide, I could initialize openjump project on gitub
(openjump-gis/openjump) and convert it to jts 1.18.
It is not perfect (I could not convert 1.5 post_release
<https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/tags/1.5%20post_release>
tag because of the whitespace in the name :-(), but all in all, I think it is OK.
tag '1.5 post_release' seems to be there with a %20, or am i missing something?
Please, have a look and let me know if you think so.
commit history seem to be identical to sf.net svn, though we're missing 2years
because of an improper svn mov from /trunk/openjump to /trunk/core . just for
completeness sake we should probably transfer this as into a history branch if
someone wants to research changes to a specific source file.
Would you consider creating a specific repository for these 2 years
rather than a branch? It would probably reduce the size of the main
repository, which is already quite large (~750MB).
See these considerations:
https://docs.github.com/en/github/managing-large-files/what-is-my-disk-quota#file-and-repository-size-limitations
As the OJ repository will only come larger over time, it could slow the
fetching process.
The creation of a specific repository could probably be considered as
well to store the former SVN "branches", i.e. oj_stable_1_2 (updated 14
years ago by Stefan Steiniger), 1.2 (updated 14 years ago by Stefan
Steiniger), paustin (updated 14 years ago by Paul Austin), 1.3 (updated
12 years ago by Stefan Steiniger), sstein@1863 (updated 11 years ago by
Larry Becker) and stable%201.5 (updated 9 years ago by Michael Michaud).
All the tags would stay, including the ones in link with the 1.2 and 1.3
versions listed in branches (were these branches some pre-release tests?).
I could compile but I still have a problem to run maven.
I did not migrate plugins at all (not sure how we must proceed yet, some
options must be discussed)
sure, one step after the other. no need to hurry things. generally i'd be in
favour of one branch per plugin, but might be swayed otherwise.
Ede, do you mean one repository per plugin rather than one branch?
If in the future, the plan is to create/add a plugin manager, the option
to create a repository per plugin could facilitate their maintenance,
especially if the OJ distribution can be used as a Maven dependency for
these plugins.
There are probably plenty of things to improve and fix before we start again to
add new code.
I'll try to list some more precise points to discuss in a future mail.
ok, looking forward to it. ..ede
Eric
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
