Eclipse Strings externalisieren -- properties-Dateien in separatem Ordner?

[kceenav]

Das Externalisieren mithilfe des Eclipse-Assistenten ist ja grundsätzlich kein Problem. Wenn man dann allerdings anschließend sein Projekt als lauffähiges JAR "exportiert", sind die properties-Dateien in dem JAR mit drin -- je nach Paket-Struktur an vielen unterschiedlichen Stellen.

Das kann doch wohl nicht das übliche Endergebnis sein, das an Endnutzer herausgegeben wird, oder?

So müsste man ja bei jeder Ergänzung/Änderung, die sich ausschließlich auf diese Sprach-Dateien bezieht, gleich das ganze Programm neu erstellen. Was mir viel zu aufwendig und umständlich erscheint.

Wie kann man die properties-Dateien in einem von den Klassen separaten Verzeichnis bündeln, so dass später jederzeit deren Inhalt (bzw. die den unverändert bleibenden Schlüsseln zugeordneten WERTE) geändert werden kann, ohne sonst etwas zu tangieren?

 

[Wildcard]

Du kannst im Wizard doch angeben welche Properties Datei verwendet werden soll.
Wie du die Dinger anschließend auslieferst ist erstmal dein Bier, das regelt dein Build/Deployment Prozess.

 

[kceenav]

Du kannst im Wizard doch angeben welche Properties Datei verwendet werden soll.

Die Optionen für die Properties-Datei habe ich gesehen. Was mir da aber zu fehlen scheint(!), ist die Möglichkeit, sämtliche Properties-Dateien in einen Ordner AUSSERHALB des SRC-Ordners zu verfrachten.

So wie es aussieht, ist das wohl grundsätzlich (zunächst?) nicht möglich. Dann passiert aber bei der Erstellung eines lauffähigen JARs mit Eclipse das, was mir zumindest überflüssig erscheint, nämlich dass pro Paket (bei der vorgeschlagenen Vorgehensweise) wenigstens eine (der späteren..) Sprach-Variante(n) mit den Class-Dateien zusammengepackt wird. Mir scheint(!), das müsste doch irgendwie anders gehen ... ?

Wie du die Dinger anschließend auslieferst ist erstmal dein Bier, das regelt dein Build/Deployment Prozess.

OK, das heißt also, die String-Externalisierung und die Ordner-/Datei-Struktur der späteren Auslieferung sind 2 Paar Schuhe. Leuchtet mir ja ein.

Nur weiß ich weiterhin nicht, wie ich den "Übergang" von der Ausgangssituation -- properties-Dateien sind durch Eclipse "untrennbar"(?) mit dem Verzeichnis der Class-Dateien verbunden (durch den "Pfad", anhand dessen nach dem passenden ResourceBundle gesucht wird) -- zu der gewünschten Situation mit einem separaten Ordner für ALLE Sprach-properties hinbekomme.

In dem Zusammenhang fällt mir ein, dass man bei den sonstigen JAVA-Libraries ja beim "Export" eines lauffähigen JARs die Wahl hat, selbige mit ins JAR zu packen oder eben in einem getrennten lib-Verzeichnis zu halten. Ist das Gleiche vielleicht auch mit einem Ordner möglich, der die gesammelten Sprach-properties enthält?

 

[Wildcard]

Die Optionen für die Properties-Datei habe ich gesehen. Was mir da aber zu fehlen scheint(!), ist die Möglichkeit, sämtliche Properties-Dateien in einen Ordner AUSSERHALB des SRC-Ordners zu verfrachten.

Es gibt nicht *den* Sourcefolder. Du kannst einen sourcefolder aus einem anderen Projekt verwenden, oder einen zweiten source folder in deinem Projekt anlegen und ihn zB resources nennen.

So wie es aussieht, ist das wohl grundsätzlich (zunächst?) nicht möglich. Dann passiert aber bei der Erstellung eines lauffähigen JARs mit Eclipse das, was mir zumindest überflüssig erscheint, nämlich dass pro Paket (bei der vorgeschlagenen Vorgehensweise) wenigstens eine (der späteren..) Sprach-Variante(n) mit den Class-Dateien zusammengepackt wird. Mir scheint(!), das müsste doch irgendwie anders gehen ... ?

Wie gesagt, es beleibt dir überlassen wie du alles verpackst. Wenn du properties und Code komplett trennen willst, dann mach ein zweites Projekt in das nur Properties Dateien kommen.

In dem Zusammenhang fällt mir ein, dass man bei den sonstigen JAVA-Libraries ja beim "Export" eines lauffähigen JARs die Wahl hat, selbige mit ins JAR zu packen oder eben in einem getrennten lib-Verzeichnis zu halten. Ist das Gleiche vielleicht auch mit einem Ordner möglich, der die gesammelten Sprach-properties enthält?

Vergiss mal das 'Runnable Jar', das ist eine convinience Funktionalität für Hobby Projekte oder wenn man schnell was ausprobieren möchte. Du brauchst einen Build Prozess der dir deine deliverables in der Form zusammenstellt wie du sie haben möchtest. Die Standardtools dafür sind meistens Maven oder ANT.