Hallo. Am Freitag, 6. November 2009 schrieb Frederik Ramm: > Beides ist nur an das Vorhandensein bestimmter Klassen im $CLASSPATH > geknuepft. Man koennte also recht leicht zusaetzliche .jar-Files bauen, > die z.B. weitere Sprachen oder z.B. die bzip2-Klassen enthalten, und > wenn JOSM die beim Start findet, geht alles. Eigentlich muesste man den > existierenden Plugin-Mechanismus dafuer vergewaltigen koennen, denn der > tut auch nichts anderes, als Klassen zur Verfuegung zu stellen... aber > da muesste ich eine Methode finden, wie bestimmte Plugins nur fuer den > "Lean JOSM" zur Verfuegung stehen und nicht fuer andere JOSMs, sonst > gibt das Chaos.
Naja, wenn JOSM (-core) weiter wächst, wird es vielleicht mehr Unterstützung in der Community geben, diese Features nicht mehr per default mit auszuliefern. Schließlich ist der Sinn von Plugins dass man das auslagert was nicht jeder braucht. Ich denke z.B. dass ein Sprach-Paket (egal welches) weniger verbreitet ist als z.B. ein wms-plugin oder ein validator-plugin und die Integration aller Sprachen eigentlich keine sinnvolle Sache ist (einfachen Installationsprozess vorausgesetzt). Die genannte Kollissionsbehandlung wäre also IMHO maximal ein Übergangsszenario, denn vorausgesetzt dass das gut funktioniert, spricht ja wenig dagegen, die JOSM-Mainline um diese Features zu kürzen und diese als Plugin (oder whatever) anzubieten. Es sollte dann natürlich noch einen JOSM-bloated geben, der das alles (und jede Menge andere Plugins) wieder enthält. Für die Bandbreitenfetischisten oder für USB-Sticks und offline-editing. Gruß, Bernd -- A: Weil es die Lesbarkeit des Textes verschlechtert. F: Warum ist TOFU so schlimm? A: TOFU F: Was ist das groesste Aergerniss im Usenet?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
