Move jmapviewer to a separate repository

[michael2402]

Currently, jmapviewer is hosted on the OSM SVN repository and included as svn:external.

We want to get rid of svn:external

• Include it in JOSM using ivy instead of snv:external (the ivy patch is ready to be applied for this)

We want to make it an independent project

• Convert jmapviewer to a git repository
• Move the repo to our gitlab server created in #16857
• Change the build script to use gradle instead of ant (not relly needed, but we want an easy project to start and use the same build system for everything)

-- Moving to gradle allows us to have the same maven config for all projects.

• Set up continuous integration there
• deprecate the old SVN repo (delete / archive / remove all links)

[floscher]

JMapViewer contains two translatable strings:

• Background Terms of Use
• Opening link not supported on current platform (''{0}'')

These strings should be added to ​https://trac.openstreetmap.org/browser/subversion/applications/editors/josm/i18n/specialmessages.java until the continuous integration of the new jmapviewer project generates a *.pot file in continuous integration.

[stoecker]

Hmm. Actually I feel we should go the other way round. The project #15229 is the goal to modularize the JOSM core to make it more useful for outside use. The map viewer was an essential component of JOSM and went that path a lot earlier, so it could be used outside.

It started as the slippymap plugin and got redesigned as own library. Then the plugin was integrated in core and then development of the library was taken over by JOSM core developers. As there was always demand for keeping it usable outside JOSM it stayed that way although that sometimes needed additional care.

When the whole JOSM core is going that way, maybe it is time to re-integrate the component into the core as module?

[michael2402]

Currently, we don't have a module system for core (and we won't have a full one for at least one year).

Our goal was to just integrate it the same way we want to do with other self-built dependencies (gettext, svgSalamander, ...). So acually the goal is to move source code away from the single JOSM repository instead of adding it.

[stoecker]

Currently, we don't have a module system for core (and we won't have a full one for at least one year).

When infrastructure decisions are taken 1 years is nothing I consider relevant.

Our goal was to just integrate it the same way we want to do with other self-built dependencies (gettext, svgSalamander, ...).

I'd be more willing to agree to such an idea if you could show a plan how to solve the security implications of distributed source code.

So actually the goal is to move source code away from the single JOSM repository instead of adding it.

Security implications left aside:
To which advantage? Singular projects are fine if they are independently managed, but the reality looks different. After some time the maintainers loose interest and JOSM has to take over maintaining. Doing that at a lot of different places only adds a lot of additional work to the JOSM core members. Have a look at all the places where we already have to take care. Why should it be a good idea to add more?

[michael2402]

A long-term goal of the module system is to add the jmapviewer as a JOSM module. For now, we wanted to go that way to make migration with preserving history easier, because the path then would be to migrate JOSM to git do a merge of the two git repository heads.

But for the transition period, jmapviewer would be our testing ground for testing the build / release system and for testing how a sooth transition to a modularized JOSM core is possible, since it currently is the only JOSM module that is already available.

[floscher]

I'd be more willing to agree to such an idea if you could show a plan how to solve the security implications of distributed source code.

When discussing this at the HackWeekend we agreed to only use artifacts from our own infrastructure ( https://josm.openstreetmap.de/nexus ).

I think we could also pin the checksum of jmapviewer.jar (so the JOSM build downloads the *.jar and fails if the checksum does not match.
It would also be a good idea to sign the build artifacts on our Nexus with PGP (by the way: AFAIK that's a requirement for artifacts published to Maven Central).

Such additional mechanisms would be a good idea, but if your attack scenario would be that an attacker puts a rogue *.jar file on our Nexus, the attacker would probably also be able to circumvent such mechanisms (by modifying JOSM directly or reading the private PGP key used for signing and publish a rogue *.jar).

[Don-vip]

Replying to floscher:

It would also be a good idea to sign the build artifacts on our Nexus with PGP (by the way: AFAIK that's a requirement for artifacts published to Maven Central).

OK I'll look into this.

[michael2402]

For the beginning, it would be perfectly fine to have a reference to the JOSM nexus (https) and just pull from there, without any checksums, assuming that our server (where we host git / ...) and our CI runners (that actually generate the artefacts) are safe.

[floscher]

Replying to michael2402:

For the beginning, it would be perfectly fine to have a reference to the JOSM nexus (https) and just pull from there, without any checksums, assuming that our server (where we host git / ...) and our CI runners (that actually generate the artefacts) are safe.

Yes, that's what I meant. As long everything is running on our infrastructure that we have control over, we can trust the artifacts. In case of a potential attack, checks of signatures or checksums wouldn't help much, since such an attack would probably compromise the whole server not only the Nexus repo isolated.

So PGP signing would be nice-to-have but not necessary as long as everything is on the same server. Version pinning using a checksum wouldn't be needed.

Replying to Don-vip:

OK I'll look into this.

With Gradle this can be done using the ​Signing plugin, the ​josm-atlas plugin already signs their releases.