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 _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
