[josm-dev] Refactoring of the JOSM architecture vs. Plugins

[J.H.]

Hi,

it seems like this is a recurring topic on this mailing list, but this
only goes to show that there is an issue burning many people: the JOSM
architecture and design has countless deficits, but there is little hope
of fixing them while the Plugin-"API" consists of tons of public fields.
In know that there is a proof-of-concept JOSM-NG, but bringing it to the
point where JOSM is right now doesn't quite seem to be realistic given
any reasonable time-frame.

Therefore I propose to refactor the current code base under the
following assumptions:
- It is not possible NOT to break compatibility with any plugin, so we
better don't even try.
- It is not realistic to design a plugin-API at this point, as the
requirements for such an API are not fully understood.
- The refactoring can frequently be done in a way such that existing
plugins are refactored on-the-fly.

This boils down to the following approach:
- Assess which plugins are considered critical.
- Make the source code of critical plugins available in the SVN
repository if not already there.
- Identify plugins which might just as well be moved into the JOSM code
base (I'm sure there's plenty of code which doesn't have to be a plugin).
- Introduce an API version management for plugins (let a plugin return
its expected API version. Assume pre-version-management version on
NoSuchMethodError).
- Make sure that all plugins in the repository actually compile. Move
them into an attic area if they don't.
- Make it easy for refactorers to run a workspace with all the
(critical) plugins checked out.
- By the way of refactoring, clean up the code design, and create
well-defined APIs as we go along.
- Publish API change notes to give third-party plugin developers a
chance of keeping up.

Well, what do you think? Is this a workable approach?

Joerg