Bibliothek statt GUI

[bodum]

Wurde schon mal darüber nachgedacht, die Anwendung auch als Java-Bibliothek anzubieten? Das wäre Ideal, um das in JOSM einzubauen, damit man die Konvertierung nicht machen muss, sondern direkt in JOSM den Track laden und direkt für OpenStreetmap bearbeiten könnte.

[routeconverter]

Hallo bodum,

darüber habe ich noch nicht nachgedacht. Du bist der erste der fragt. Da bin ich neugierig ;-)

Eigentlich sollte das jetzt schon gehen. Lade das Kommandozeilen-JAR von der Downloadseite herunter und starte mit der Klasse NavigationParser. Klappt das? Oder wie stellst Du Dir das vor?

JOSM ist doch auch GPL, oder?

[bodum]

Wie wäre es mit einer Trennung des SourceCodes in 3 Teile:

- Bibliothek
- GUI
- Kommandozeile

Dann könnte man die Bibliothek direkt nutzen für alles mögliche. Laden von Dateien, benutzung der Objekte im Speicher, schreiben in verschiedenen Formaten. Und die Bibliothek bringt keine GUI-Jars mit, sondern nur das was wirklich gebraucht wird.

Gibt es eigentlich einen Grund für deine Aufteilung der Module? Ich habe im SVN sehr viele unterschiedliche Intellij-Module gesehen, die jeweils nur ein paar Klassen enthalten?

JOSM ist GPL, ich selber betreue das allerdings nicht, ich will nur ein Plugin dafür in GPL schreiben. Eines der GPL-Projekte, das ich betreue ist der TV-Browser.

[routeconverter]

Die von Dir vorgeschlagene Trennung gibt es auf Modul-Ebene bereits (ok, sie ist noch etwas feiner ;-):
* common, navigation-formats entsprechen dem was Du Bibliothek nennst
* route-converter-cmdline ist für die Kommandozeilenversion
* der Rest ist fürs GUI

Klar gibt es einen Grund für meine Aufteilung: Klare Aufgabe je Modul, klare Modulabhängigkeiten. Wie würdest Du das anders aufteilen wollen?

[bodum]

Also ich war etwas erstaunt, das es so viele Pakete gibt mit so wenig Klassen. Ich würde die Module eher als Packages aufteilen innerhalb der 3 Module, common, navigation-formats. Dann hast du da noch jaxb5, jaxb6, jdic-current, route-converter5+6 usw.

Wenn du das klar in 3 Module packen würdest, mit entsprechenden Namen, sollte schneller klar sein, was wo ist und wieso was wo liegt und was man wofür braucht.

Ich denke, die Verzeichnisse mit Versionsnummern bräuchtest du nicht, oder? Schließlich nutzt du doch SVN, da hast du doch deine Versionsverwaltung integriert. Oder gibt es einen Grund dafür?

[routeconverter]

Naja, jaxb5 und 6 sowie route-converter5 und 6 benötige ich schon einmal, um Java 5 und 6 parallel entwickeln zu können.

jdic-current und jdic-0.9.3 sind für den anvisierten Mac-Support nötig.

Nach meiner Erfahrung sind kleinere, feingranularere Module sehr viel nützlicher als große Codeklumpen. Ich strukturiere Module nach Funktionen und nicht nach dem Codeumfang, da ein Modul fast nichts kostet, im Nachhinein aber sehr aufwändig einzuführen ist. Auch dies einr Erfahrungen aus 2 Projekten mit > 1,5 Mio Codezeilen ;-)

[bodum]

Naja, sooo aufwändig ist es nicht, neue Module einzuführen. Ich habe hier meistens Maven als Build-System, da ist sowas kein problem. Neues Modul erzeugen, Klassen dahin verschieben, Abhängigkeiten in den Poms korrigieren. Fertig.

Sowas mache ich ab und zu mal in refactoring-phasen der Projekte, soald das notwendig wird. Auch bei > 1,5 Mio Codezeilen .

Wichtiger wäre für mich, das Projekt übersichtlich zu halten und für einsteiger klar strukturiert zu haben. Das ist bei OpenSource wichtig, damit du weitere Mitarbeiter (wie mich ) findest.

Hast du irgendwo eine Beschreibung aller Module, was diese machen und wie die voneinander abhängen? Du baust ja nicht mit Maven, da könnte ich das direkt sehen ...

[routeconverter]

Eine Beschreibung der Module habe ich nicht. Ich bin ein Fan von sprechenden Namen ;-).

Im Moment baue ich mit ant aus 4 Gründen:
- Ich kann mit Java 5 und Java 6 gleichzeitig entwickeln
- Ich muß die thirdparty-Jars patchen
- Ich weiß nicht, wie man das beides mit Maven hinbekommt
- ant ist einfacher

[bodum]

Also für mich sind die Namen anscheinend nicht sprechend genug . Kannst du bitte sagen, welches modul was macht, damit ich das besser verstehe?

Und was musstest du an den third party jars patchen? Hast du das zurück commited?

[routeconverter]

Also für mich sind die Namen anscheinend nicht sprechend genug . Kannst du bitte sagen, welches modul was macht, damit ich das besser verstehe?

build = Build the project
catalog = Interact with the routecatalog service http://www.routeconverter.de/routecatalog/
common = Common code to all modules
common-gui = Common code to all GUI modules
jaxb5,jax6 = JAXB related wrappers for Java 5,6
jdic-0.9.3, jdic-current = JDIC related code
navigation-formats = Read & Write all supported Navigation formats
route-converter = the GUI you see if you start the program
route-converter5, route-converter6 = RouteConverter for Java 5,6
route-converter-cmdline = The command line version
routes = test data
route-synchronizer = a prototype for GUI-based conversion of directories
thirdparty = 3rd party code, -stripped to reduce packaging size