some more questions 1. did it ever run through completely? 2. why start at revision 859? 3. did you try https://github.com/nirvdrum/svn2git#debugging ?
it'd probably more stable if you could work with a full local checkout.. ede On 14.08.2020 21:26, Eric wrote: > The command is to migrate the complete project, including its history, from > svn to git: > svn2git https://svn.code.sf.net/p/jump-pilot/code/core --exclude docs > --revision 859:6242 --authors ../authors.txt > > I first tried without excluding the docs folder. The revision parameters > match the first and the 1.15 revisions. > > So yes, it's a complete checkout of the core (except the 1.15+ commits), > including trunk, tags and branches, and their reconstruction and migration to > a local git project. > > Eric > > On 14/08/2020 20:02, edgar.sol...@web.de wrote: >> probably just sf.net's svn acting up. it sometimes throws weird errors that >> resolve itself after a time. i guess they get fixed on their servers. who >> knows. >> >> anyway. what is it you are doing when it errs out? a complete checkout? what >> commands are you running? can you give some context? >> >> ..ede >> >> On 14.08.2020 20:48, Eric wrote: >>> Hi, >>> >>> I'm encountering a problem during the local migration (ra_serf: The server >>> sent a truncated HTTP response body) when I try to do it from revision 859 >>> to revision 6242. >>> >>> I tried to exclude the 'docs' folder to reduce the size of it, without much >>> success (still the same error after an hour or two during the migration >>> process). >>> >>> Could one of you try these two commands (as indicated here: >>> https://stackoverflow.com/questions/27267742/why-do-i-get-svn-e120106-ra-serf-the-server-sent-a-truncated-http-response-b) >>> svn cleanup >>> svn up >>> >>> Thanks in advance. >>> Eric >>> >>> On 14/08/2020 11:12, Giuseppe Aruta wrote: >>>> 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 >>> >>> >>> _______________________________________________ >>> 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
