Eric, surely we can use whatever we decide as "email" as long as it fit's the syntax or? as all of these are sf.net users we could simply use the <sfnetusername>@users.sourceforge.net .
..ede On 11.08.2020 11:50, Eric wrote: > The problem is that email addresses are required to be able to keep the > authors. > > A solution could be to use the email addresses for the active developers and > to use another generic email address for all the others (this one could be > one created for this sole purpose using gmail). This would technically work. > > Eric > > On 11/08/2020 10:29, edgar.sol...@web.de wrote: >> working mail addresses will be difficult to get for everyine and generally >> unnecessary as well. just need to keep the history and committer ids to >> enable retracing changes in the future as well. >> >> ..ede >> >> On 10.08.2020 15:52, Eric wrote: >>> Here is the list of all the SVN authors (and their number of contributions) >>> according to the logs: >>> beckerl 197 >>> bertazza 29 >>> bgudehus 6 >>> clark4444 6 >>> edso 1305 >>> elnico 54 >>> eric.lemesre 4 >>> infinityedge 2 >>> jammerhund 47 >>> javamap 10 >>> jratike80 22 >>> kdneufeld 2 >>> lreeder 1 >>> ma15569 602 >>> mentaer 465 >>> michaudm 1619 >>> paul_d_austin 38 >>> s-l-teichmann 1 >>> stranger 87 >>> >>> If you want to keep track of them in the possible future Git repository, a >>> conversion file needs to be created, for example (with one author per line): >>> michaudm = Michael Michaud <em...@test.com> >>> >>> We should maybe do this outside this mailing list to avoid creating a list >>> of public email addresses. >>> >>> For info, I easily managed to locally create a Git repository containing >>> the 1.15 release of OpenJUMP, using the 6242 revision. I'm waiting for your >>> different answers to move to the next step. >>> >>> Best, >>> Eric >>> >>> On 10/08/2020 14:42, Eric wrote: >>>> Hi Ede, >>>> >>>> Thanks for your welcome and for your answers. See my inline replies for >>>> some of them (I deleted the other parts). >>>> >>>> On 09/08/2020 16:40, edgar.sol...@web.de wrote: >>>>> hey Eric, >>>>> >>>>> welcome to the team! see my answers below >>>>> >>>>> 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. >>>> >>>>>> This is quite a good news because >>>>>> if the deegree dependency is updated to its latest version (3.x.x), >>>>>> which relies on JTS 1.15, >>>>>> then, theoretically, only the import statements and a few other >>>>>> com.vividsolutions directly used in the code >>>>>> need to be modified. >>>>> yeah, probably not. deegree2 is afaics used primarily or exclusively for >>>>> the WFS extension and i remember checking out deegree3 as a drop in for >>>>> deegree2 but failing miserably. that's why i stuck with deegree2 happy to >>>>> have at least a working WFS extension for the time being. >>>>> >>>>> but again, we can remove WFS from core for OJ 2.x and come up with a >>>>> working extension later (if at all). >>>> It seems to be a good compromise for the time being as the migration from >>>> deegree-core 2 to deegree-core 3 isn't straightforward. >>>> >>>>>> - the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic >>>>>> due to the jts-io >>>>>> pom type only, but once imported, this part of the code will be >>>>>> functional again, >>>>> how do you figure? com.vividsolutions.jump.io.geojson was written by >>>>> myself from scratch utilizing google's json-simple . it holds no >>>>> dependency apart from the jts geometry code. maybe myself placing it in >>>>> this package has mislead you >>>> Have a look at the GeoJsonReader class for example, and the method >>>> MapGeoJsonGeometryReader (see the comment), or the >>>> GeoJSONFeatureCollectionWrapper class. You will see that there is a >>>> dependency to JTS io. >>>> It doesn't mean that there is a real dependency in the way it works, but >>>> JTS io (now jts-io-common which includes the GeoJSON code) is needed for >>>> the code to compile. >>>> >>>>>> - some classes have been deprecated, removed, or simply moved in the new >>>>>> JTS versions, >>>>>> such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. >>>>>> New interfaces >>>>>> have been created in JTS. It shouldn't be too complex to find a solution >>>>>> or a workaround, >>>>> agreed >>>> After the JTS upgrade, only two classes require some changes: >>>> - org.openjump.core.ui.plugin.tools.ReducePointsISAPlugIn -- relatively >>>> easy to solve, >>>> - another written by Michaël, com.vividsolutions.jump.geom.MakeValidOp. >>>> For this one, a few JTS constructors have evolved. The problem is linked >>>> to the 4th dimension, dimension that can't be retrieved any more with a >>>> simple getter. One temporary solution could consist in the creation of a >>>> class which extends the current JTS one with an additional getter / setter >>>> for the dimension. >>>> >>>>>> Once these problems of imports are solved, the JTS update should be >>>>>> relatively >>>>>> straightforward, and some work will probably be needed to update the code >>>>>> based on deegree. I tried to update one of my plugins, it took me seconds >>>>>> to do it, and I know that it would be exactly the same for the others, >>>>>> just by >>>>>> replacing com.vividsolutions.jts by org.locationtech.jts. >>>>> sure. problem is not the port but gathering all plugin sources, setting >>>>> up build env, porting and releasing the new modification for each and >>>>> everyone. on the other hand, there is no alternative since locationtech >>>>> forced our hand >>>> I answer this point later in the discussion, including a possible >>>> migration to Git. >>>> >>>>> my maven-fu pretty much is compiled in the OJ pom. never needed it before >>>>> or setting up the snapshot/release profiles. so you are on your own >>>>> there. had to figure out some Ant for some finetuning but that's it. but >>>>> it's pretty well documented, so we will get it into shape if something >>>>> has to be changed. >>>> OK. Thanks. >>>> >>>>> going forward i'd suggest you (Eric) >>>>> 1. work with the stable OJ 1.15 check out >>>>> 2. remove WFS, here is the adding commit from 2014 >>>>> https://sourceforge.net/p/jump-pilot/code/4219/ >>>>> essentially it is the package 'de.latlon.deejump.wfs' >>>>> 3. fixup a running port to JTS 1.15+ >>>>> >>>>> if that worked out you may holler and we can decide how to proceed. i >>>>> could imagine >>>>> 1. doing a "final" OJ 1.16 release only updated on critical issues >>>>> 2. announcing and moving development focus over to OJ 2.x >>>>> 3. branch OJ 2.x dev from the OJ 1.16 and apply the changes researched by >>>>> Eric >>>>> 3. extension fixup, extension fixup, ... >>>>> >>>>> bonusbonusbonus >>>>> b1. maybe even finally porting the svn repo to git (to attract more >>>>> comitters and make it easier to apply contributions), what's important to >>>>> me here is to keep our commit history so we can still retrace changes >>>>> after years and find out why they were done this way by the commit >>>>> messages or by whom to ask them >>>>> b2. tackling java's module system jigsaw, as classpath based loading >>>>> looks like to become a thing of the past >>>>> >>>>> so far, so hot ..ede >>>> My plan was nearly identical. Here it is: >>>> - Using OJ 1.15 core including trunk, tags and branches, >>>> - Migrating the code to Git based on something like this: >>>> https://www.atlassian.com/git/tutorials/svn-to-git-prepping-your-team-migration. >>>> It includes the preservation of the commit history (critical point) >>>> including the authors of these commits (more details here -- authors.txt >>>> --: https://www.atlassian.com/git/tutorials/migrating-prepare) -- I don't >>>> know yet if it's possible to link the authors to new Git accounts (this >>>> would be great). Note that this migration automatically recreates the tags >>>> and branches, >>>> - Creating a repository with this code on Github or Gitlab (see below for >>>> an open discussion about it), >>>> - At this stage, I would drop the WFS part of the code, including the >>>> package 'de.latlon.deejump.wfs' as Ede mentioned but also the >>>> 'org.deegree' one. I would also drop the deegree-core dependency in the >>>> pom.xml, >>>> - Removing the two Maven repositories mentioned in a previous message, >>>> adding the new one as mentioned too, >>>> - Updating JTS to a 1.15+ version, ideally the 1.17 as it doesn't change >>>> much between 1.15 and 1.17, both for JTS and JTS io common for the GeoJSON >>>> part. Replacing all com.vividsolutions.jts by org.locationtech.jts and >>>> working on a workaround for both ReducePointsISAPlugIn and MakeValidOp >>>> classes. Push the results once it compiles / works, >>>> - Creating a small document containing all the different undertaken steps. >>>> - (Bonus) Upgrading the Log4j dependency to v2 and therefore removing the >>>> current security issue in link with it. >>>> >>>> >>>> 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, >>>> - The idea is to create a temporary Git project/repository as Ede >>>> mentioned too. There are two main platforms for that, GitHub and GitLab. >>>> Let me know which one you prefer, knowing that it is possible to have both >>>> solutions, working only on one, with a mirroring for the other using this >>>> solution (this includes automated push/pull): >>>> https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html >>>> - 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, >>>> - 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? >>>> - Have you already got some GitHub/GitLab accounts that I could use to let >>>> you access the project as administrators? >>>> >>>> >>>> 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. >>>> >>>> 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. >>>> >>>>> ps. "how hard can it be?" - https://dilbert.com/strip/2020-08-07 >>>> >>>> Thanks a lot for your views on that Ede. >>>> >>>> Please let me know what you prefer and I'll act accordingly. >>>> >>>> Best, >>>> Eric >>> >>> >>> _______________________________________________ >>> 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
