I’m going to reply to some things in this thread.
On-topic:
Yep. Running JOSM with a newer JRE will “magically” make it work on Wayland natively. This is because JOSM uses Swing for the UI elements, and we don’t do any window environment specific things ourselves.
Off-topic
I’ve spent quite some time working on a conversion for the JOSM plugin repo to git, and JOSM core to git. I gave @stoecker access to the GitHub repo with the current conversion scripts. If you want to finish up the conversion, I’m more than open to replying to questions (poke me via @vorpalblade or on JOSM Trac). Realistically, it was probably “good enough” a few months back, but I was really trying to split out each plugin into its own repo at the same time.
This is one of the reasons why I invested time in making the maven build system. It is something that almost every IDE can import and use, although there are some quirks due to needing a josm-unittest package for plugin tests. Given the widespread use of maven, I would be extremely surprised if someone could not figure out how to get things working. If you wanted gradle/<random other build system>, those won’t happen. gradle because I’ve had way to much breakage on version updates, and the other random build systems because there isn’t good widespread IDE support.
It is also one of the reasons why I was working on-and-off on converting parts of JOSM from svn to git. The other reason is I often found myself working on multiple things at once (e.g. “1 big project + bug fixes for tickets”), and sometimes I was making changes to the same files.
Yes, I would have liked to continue working on JOSM. Rather unfortunately, I think one of the jobs I’m looking at will view continued work on JOSM as a conflict of interest.
In any case, I’ve got until Friday, and I’m trying to wrap up/clean up as much stuff as possible before I disappear.
What tooling would you suggest? If it is gradle, the answer is no. In my experience, there is almost always some kind of breakage when updating gradle between major versions, and that ended up being more work than I want to do between all the plugins that used it. maven should be more than enough for new developers since it is extremely easy to import the project into an IDE.
If it is github, the first step is always going to be converting the JOSM repos from svn to git.
If it is git, I’ve got a WIP repo for scripts to do the conversion that I shared with @stoecker. You can take a look at the generated repos at tsmock (Taylor Smock) · GitHub – I just updated them last week.
If it is “CI”, we already have GH workflows for JOSM core and I wrote a GH action for JOSM plugins.
The versioning system isn’t silly; it is a simple incrementing number. It does mean that we can’t do point releases, but that hasn’t been a big issue.
As noted elsewhere in this post, I’ve got scripts to convert JOSM and the JOSM plugin repo to git. Also, as noted elsewhere in this post, I’m still not happy with the conversions. They are probably “good enough”, but I was hoping to get something that was as close to perfect as possible. As far as patches go, I did accept patches by PR on GitHub, if people poked me about them. TBH, this is one area where I failed; looking at other people’s patches. If I got poked, I typically looked at them. But I had to get poked, since I usually forgot to look at the patches report on Trac.
The “awful bug reporting” system has one key advantage over GitHub and most other git forges: anonymous bug reports. Said bug reporting system is also part of the “archaic wiki” which has a ton of scripting for various things that could be replicated via GitHub actions. Do you want to spend the time on converting stuff? It should be fairly easy to do. Here are some possible steps:
- Write script that pulls down diffs from relevant wiki pages and applies them to the repo
- Write GH action that runs daily/weekly and syncs the wiki page history to the git repo
- Publish GH pages and test via adding additional sites to the respective JOSM subsystem
As far as the “perpetually out of date editor layer index” goes, it has layers that the ELI doesn’t have, much like the ELI has layers that our index doesn’t have. If you want to make the JOSM index more synchronized with the ELI, feel free to help out: https://josm.openstreetmap.de/wiki/ImageryCompare .
In short, instead of complaining, you could have worked the problem. Of all your points, the one I agree with the most is the “archaic wiki”. I’m worried that Trac will lose all support and a major vulnerability will be found. However, to move off of Trac to anything else, the following needs to happen:
- Convert the repos from
svntogit(see previous comments on the conversion scripts I have) - Make git mirrors of the various wiki pages that need scripts and add CI scripts for the intended platform (GitHub/Gitea/Forgejo, Gitlab, etc.)
- Make git mirror of help pages
- Synchronize existing tickets with new system. Make certain that tickets with patches attached are PRs instead of issues, but try to keep the current numbering system so that existing references don’t break or can be trivially rewritten.
- Convert remaining Jenkins CI scripts to CI scripts for intended platform (optional)
