Hi Peppe,
On 21/08/2020 13:05, Giuseppe Aruta wrote:
Thanks Eric, next week I will take sometime to study the repository
and all the page you sent.
Some questions, proposals.
A) Regarding plugins,
Do you think that grouping together plugins iwith similar technical
aspects into one source could help to simplify/speed the transition to
Git?
For instance, I am considering to group together CAD toolbox, Advanced
Measure and Color chooser plugins. Of coarse thus should be done
before porting everything to Git.
This is a question of: migration practicality vs project
re-structuration vs long term maintenance.
As far as I currently know, it would seem rather difficult to migrate
all the plug-ins into a single repository because of their individual
structures. Some of them have an internal standard layout (trunk,
branches, tags), some others have a non standard one, some others have
none. But this doesn't mean that if required (single repository), it
should be avoided simply based on the migration complexity. The
migration will be done once, but the maintenance will have to be on a
"daily/weekly/monthly" basis after that.
This is the reason why I thought it would be a good time to introduce a
plug-in manager. I started to look at different options. You probably
already had discussions about it on this list but I didn't look at it yet.
A plug-in manager would allow to split all the plug-ins into individual
repositories, or to group them, as you wrote, based on their technical
aspects / dependencies. If the core of OpenJUMP is regularly exported in
a Maven repository, then all plug-ins could be automatically tested
against it for each change. On the other hand, if each plug-in has its
own repository, will it be harder to manage them all? Another solution
would consist in migration these plug-ins individually, then to
restructure them and to move them inside one or several new
repositories. They could be considered as modules, and could maybe
depend on a common parent Maven configuration. This would probably help
to maintain, deploy, and test them in an automated way (not for the code
maintenance of course, but at a global configuration level).
The plug-in manager could also simplify the way the project is built at
the moment as some plug-ins need to be shipped in during each release.
With a plug-in manager, only the core could be provided then the
plug-ins could be easily loaded afterwards.
I started writing a bit about some of these aspects, but nothing
substantial for the moment. And as you know how OpenJUMP works far
better than me, I am quite happy to see what you wait for your
suggestions, rather than proposing something a bit in the dark. So
please let me know what you think, especially if what I wrote above
makes no sense to you.
B) WFS could be shipped as external plug-in. Anyhow.
You're right. But it would probably be easier to keep it internally to
allow a centralised layer management.
C) good news from Sextante GIS planet.
https://joinup.ec.europa.eu/svn/sextante/ has also source code from
Sextante vers. 1.0 which seems to be the one we shipped. I recompiled
it with JTS 1.7 and used a OJ core adapted with JTS 1.7 to test
various raster plugins with success.
I am considering to open a repository on Git to store the Sextante lib
source and OJ binding.
Please do. It could help to test the automated builds.
Eric
Peppe
Il ven 21 ago 2020, 12:37 Eric <eric.openj...@thefactory.io
<mailto:eric.openj...@thefactory.io>> ha scritto:
Hi,
On 20/08/2020 19:22, edgar.sol...@web.de
<mailto:edgar.sol...@web.de> wrote:
> On 20.08.2020 19:08, Michaud Michael wrote:
>> Hi,
>>
>> Big thanks for this work Eric, seems to be very well documented.
> yup, impressively well documented!
Thanks. No problem.
>> I think we should take advantage of this work and proceed to a
more definitive
>> migration without waiting too much.
> true. but we should still put out a final "stable" because it'll
probably take some time to adapt all those missing extensions.
From a technical point of view, the migration process is still
going to
work in a couple of months.
As written in my previous message, this article highlights what
needs to
be done before the final migration:
https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git
It is often advised to avoid adding binary files. I wrote a bit about
that in the OpenJUMP context:
https://github.com/openjump-gis/openjump-migration-doc/blob/master/MIGRATION.md#2-convert-the-subversion-repository
The migration of the OpenJUMP core repository has been relatively
easy but:
- the WFS functionalities have been lost along the way. What to do?,
- some decisions need to be taken about the way(s) to migrate all the
plug-ins (individual repositories? a couple of global ones -- core,
plus, experimental, etc. --? a global one?). Their SVN structures
differ, so it isn't going to be necessarily easy to deal with that,
- would it be easier to create the plug-in manager before the
migration?
Could it help answering the last questions?,
- there are all the questions about the different builds,
especially for
those which are related to the plug-ins,
- is there a better way to link SVN authors with Git authors, rather
than using the SourceForge user addresses? (historical commits would
thus refer to current Git accounts)
- etc.
After migration, the current size of the OpenJUMP core as a Git
repository is around 540MB.
The 'docs' folder size alone is 70MB without the revision history,
and
108MB if considered. By externalising it into another Git repository
(the revision history would be kept as well), this would reduce the
global size of the main core repository by already 20%. Some other
folders could be considered. In the long term, this would probably
make
the global project easier to manage.
I just did a quick test to create a private repository for the 'docs'
folder. See (you need to be logged in to access it):
https://github.com/openjump-gis/doc-test
I used a tool directly provided by GitHub to automate the migration
(https://github.com/new/import). It is quite handy but it is
relatively
difficult to create a proper mapping between the SVN and the Git
users/authors.
So what I would suggest is to create some wiki pages in the newly
created openjump-migration-doc repository
(https://github.com/openjump-gis/openjump-migration-doc) to write and
discuss about the different options. A wiki is an easy way of
communication, or issues could be created as well. Once
discussed/closed, I could add some proper documentation to
crystallise
what has been decided.
This suggestion, even if first perceived as time consuming, could
allow
us to migrate most the OJ repositories/components, if not all, in an
easier way, and to save some a lot of time in the future. This would
also allow, if needed, to restructure some parts of the project now
(probably not the code itself, such as the tests, etc., but such as
previously described based on the 'docs' folder) rather than later,
especially if one goal is to reduce the global size of the repository.
Once again, these are just suggestions, open to discussion.
Eric
>> What about listing the tickets or tasks we want to fix before
migration (if
>> possible something we can achieve within a few weeks). Then we
could make a new
>> release and concentrate on the migration.
> agreed. we should at least prioritize. let me try to set up a
milestone in the bug tracker.
>
> sorry for spamming the list, but setting up the searchable
milestone on sf.net <http://sf.net> was a bit bothersome.
>
> we have 36 open bugs, which can now be assigned to a OJ_1.16
milestone now. when that's done we can search them on the left
side via 'Open Tickets for OJ 1.16' and fix em one by one.
>
> hands up. who want's to tag'em?
>
>> Any other proposal somebody ?
> not me :).. ede
>
>> Michaël
>>
>>> envoyé : 20 août 2020 à 17:58
>>> de : Eric <eric.openj...@thefactory.io
<mailto:eric.openj...@thefactory.io>>
>>> à : jump-pilot-devel@lists.sourceforge.net
<mailto:jump-pilot-devel@lists.sourceforge.net>
>>> objet : Re: [JPP-Devel] OpenJUMP migration documentation
>>>
>>>
>>> Just added the documentation to update JTS from 1.14 to 1.17.
>>>
>>> Eric
>>>
>>> On 20/08/2020 13:42, Eric wrote:
>>>
>>>> Hi,
>>>>
>>>> The first part of this documentation is now online:
>>>> https://github.com/openjump-gis/openjump-migration-doc
>>>>
>>>> It focuses only on the migration from SVN to Git.
>>>>
>>>> Before migrating, the reading of this article could be useful
as it
>>>> contains some good practice tips:
>>>>
https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git
>>>>
>>>>
>>>> Eric
>>>>
>>>
>>> _______________________________________________
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
<mailto: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
<mailto: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
<mailto: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
<mailto: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
