Pfad für Datei neben Jar

[Trunk]

Hallo!
Da das laden einer .xml datei zumindest bei mir nicht so recht funktioniert, möchte ich diese einfach mit der Jar zusammen in einem Ordner ausliefern.
Wie lautet nun der Pfad zu dieser?
also:

folder/Beispiel.xml
folder/test.jar

Danke!

 

[Gast2]

Das kommt ganz auf dein working directory an.
wenn du das programm per

java -jar test.jar

startest (du dich also im Verzeichnis folder befindest), dann sollte das pfad einfach

System.getProperty("user.dir") + "/Beispiel.xml"

sein.

 

[Trunk]

Das kommt ganz auf dein working directory an.
wenn du das programm per

java -jar test.jar

startest (du dich also im Verzeichnis folder befindest), dann sollte das pfad einfach

System.getProperty("user.dir") + "/Beispiel.xml"

sein.

Die .bat mit der ich es starte sieht so aus:
java -Djava.library.path=lib\ -jar test.jar

Der Vorschlag sollte also gehen, nur wenn ich das nun als URL brauche?
Wie krieg ich das hin?
Bisher benutze ich:

URL beispiel = testclass.class.getResource(path);

Funktioniert das ganze dann eigentlich immernoch in der IDE?

 

[jgh]

wenn du die Beispiel.xml direkt neben deiner Jar-Datei auslieferst, sollte es wie folgt klappen:

URL beispiel = new URL("./Beispiel.xml");

 

[nrg]

in der ide funktioniert das dann auch. du musst halt die datei an die richtige stelle kopieren . um herauszufinden, wo dein ausführendes verzeichnis ist, kannst du einfach sowas machen:

System.out.println(new java.io.File(".").getAbsolutePath());

 

[FArt]

Welchen Grund gibt es, die Datei nicht im JAR zu verpacken und über den Classloader zu laden? Alles andere ist gefrickel...

 

[jgh]

Welchen Grund gibt es, die Datei nicht im JAR zu verpacken und über den Classloader zu laden? Alles andere ist gefrickel...

ein ganz simpler Grund dafür ist, dass man -zumindest bei kleineren Projekten- schnell, einfach und unkompliziert externe Resourcen (Bilder, propertie-Dateien, u.ä) austauschen kann und das Programm dann (ohne neu zu compilieren) testen kann.

Natürlich kann man das auch innerhalb eines JAR-Files machen...ist nur ein wenig aufwendiger.

 

[FArt]

ein ganz simpler Grund dafür ist, dass man -zumindest bei kleineren Projekten- schnell, einfach und unkompliziert externe Resourcen (Bilder, propertie-Dateien, u.ä) austauschen kann und das Programm dann (ohne neu zu compilieren) testen kann.

Natürlich kann man das auch innerhalb eines JAR-Files machen...ist nur ein wenig aufwendiger.

Das ist kein Argument einen Pfusch zu machen. Denn ich muss die Ressource nicht in das JAR legen. Ich kann sie einfach so in den Klassenpfad legen. In der Echtzeitumgebung ist sie halt dann im JAR.

 

[nrg]

bei bildern oder so bin ich da schon bei dir aber alle konfigurationsdateien sollten imho nicht direkt in der jar liegen. man kann ja auch einen stream ausserhalb der jar via classloader holen

 

[FArt]

bei bildern oder so bin ich da schon bei dir aber alle konfigurationsdateien sollten imho nicht direkt in der jar liegen. man kann ja auch einen stream ausserhalb der jar via classloader holen

Klar. Aber eben über den Classloadern, nicht über das Filesystem.
Aber auch hier: nur bei Bedarf, d.h. wenn es konkret eine Anforderung ist, dass die Konfigurationsdatei extern (z.B. mit einem Editor) verändert werden können soll.