PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [Java] Jar erstellen, dass Classpath richtig berücksichtigt wird (über Eclipse Export


Hardwaretoaster
2010-07-29, 20:48:18
Ich entwickle gerade an einem Tool, wo ich entsprechende externe Ressourcen einbinden muss (die werden auf den Zielrechnern seperat vorinstalliert und können als vorhanden gelten):


einmal ein .jar, was per Manifest auf zig weitere (in nem relativen Unterverzeichnis dazu) zeigt, mache ich in Eclipse über "Add external jar"
einmal auf einen Ordner wo property-Files drin liegen, Mache ich im Build Path per add Variable und zeige auf den Pfad


Aus Ecplise heraus funktioniert das wunderbar, ich kann starten, mein Zeug ausprobieren...wunderbar.

Ich brauche aber jetzt ein jar von dem Ergebnis:
Wenn der Pfad auf das initiale jar und den Ordner wo die Property-Files drin sind im ClassPath (der Umgebungsvariable) drin sind, müsste das doch eigentlich gehen oder?

Hier tut es nicht, und ich sehe nicht warum.

Was funktioniert ist:

jar wie gehabt einbinden
das Verzeichnis mit den Property-Files nicht als Variable sondern als class folder in Eclipse einbinden
Im Export dann Executable jar auswählen und die Jar in einen Ordner neben das Ziel-jar kopieren lassen


Das mit den jars ist nicht schön, ließe sich notfalls aber noch ertragen. Aber die property-Files werden dann in das Ziel-jar kopiert. Die müssen aber flexibel anpassbar bleiben, im jar ist also kein Zustand.

Hat jemand eine Ahnung wo ich den Denkfehler mache?

Berni
2010-07-29, 23:32:29
Ich persönlich bevorzuge das Fat Jar-Plugin. Das packt alles zusammen (inkl. der abhängigen Klassen/Bibliotheken) in ein JAR. Das erspart meist ne Menge Stress mit Usern die dann doch irgendwelche falsche Bibliothek-Versionen oder Pfade haben.

HWT@Work
2010-07-30, 07:26:51
Das ist ja meines Wissens nach mit dem vergleichbar dem "Executable Jar-Export" in Eclipse 3.5.

Wie gesagt, für die jars notfalls denkbar. aber nicht für das Verzeichnis wo die property-Files liegen.
Das die entsprechend installiertz sind ist sichergestellt.

Also: Wie ist das nun mit dem ClassPath? Sind meine Überlegungen dazu richtig? Wo könnte der Fehler liegen?

Shink
2010-07-30, 08:18:39
Wenn der Pfad auf das initiale jar und den Ordner wo die Property-Files drin sind im ClassPath (der Umgebungsvariable) drin sind, müsste das doch eigentlich gehen oder?

Ich bin mir nicht ganz sicher ob ich dich richtig verstehe; so wie ich das verstehe sollte das tatsächlich gehen. Ich denke die entscheidende Frage ist aber:
- Warum willst du eigentlich dass die Properties im Classpath sind? Du könntest sie auch mit new File("bla.properties") o.ä. aus dem current working directory (oder einem Unterverzeichnis davon) laden.
- Wie genau sieht die Verzeichnisstruktur aus, wie lädst du die Properties und wie sieht der Classpath aus? Vielleicht hast du da ja einen kleinen Fehler drin?

Ich persönlich bevorzuge das Fat Jar-Plugin. Das packt alles zusammen (inkl. der abhängigen Klassen/Bibliotheken) in ein JAR. Das erspart meist ne Menge Stress mit Usern die dann doch irgendwelche falsche Bibliothek-Versionen oder Pfade haben.
Das Problem daran:
1) Libraries mit gewissen Lizenzen (ich denke das trifft sogar auf das ganze Apache-Zeug zu:rolleyes:) müssen komplett oder gar nicht mitgeliefert werden.
2) FatJar entpackt alle Libraries und packt sie in das neue, ausführbare JAR - manches Zeug wird auch entfernt. Das ist mit 1) nicht vereinbar.
3) Der TS will nicht dass seine Properties-Dateien im JAR sind denn dann kann man sie nur editieren wenn man das JAR befummelt. Für eine Konfigurationsdatei natürlich unpraktisch.

Hardwaretoaster
2010-07-30, 17:39:56
Ich bin mir nicht ganz sicher ob ich dich richtig verstehe; so wie ich das verstehe sollte das tatsächlich gehen. Ich denke die entscheidende Frage ist aber:
- Warum willst du eigentlich dass die Properties im Classpath sind? Du könntest sie auch mit new File("bla.properties") o.ä. aus dem current working directory (oder einem Unterverzeichnis davon) laden.
- Wie genau sieht die Verzeichnisstruktur aus, wie lädst du die Properties und wie sieht der Classpath aus? Vielleicht hast du da ja einen kleinen Fehler drin?


Das Problem daran:
1) Libraries mit gewissen Lizenzen (ich denke das trifft sogar auf das ganze Apache-Zeug zu:rolleyes:) müssen komplett oder gar nicht mitgeliefert werden.
2) FatJar entpackt alle Libraries und packt sie in das neue, ausführbare JAR - manches Zeug wird auch entfernt. Das ist mit 1) nicht vereinbar.
3) Der TS will nicht dass seine Properties-Dateien im JAR sind denn dann kann man sie nur editieren wenn man das JAR befummelt. Für eine Konfigurationsdatei natürlich unpraktisch.


Die Erklärung liegt in deiner Problemstellung schon erklärt.
Die jars, die ich benutzte brauchen die property-Files, daran kann ich nichts ändern... Und ja, es scheitert an Lizenzen und Co.

Der Aufruf sieht etwa so aus (hier jetzt mal den ClassPath-Teil direkt drin):

C:\Pfad\zu\meinem\Programm> java -classpath "C:\Program Files\XY\abc.jar"; "C:\XY\conifg" -jar meineJar.jar

Er fällt auf die Nase in der ersten Zeile wo auf die Lib zugegriffen wird mit einer ClassNotFoundException.

Hardwaretoaster
2010-08-01, 13:39:10
Das Ding macht mich noch wahnsinnig.. Ist vielleicht ne Lappalie wie falsche Hochkommata (wer auf die Idee mit dem Leerzeichen in Program Files kam hat auch geschlafen...), was ich aber an der Ausgabe nicht sehe?

Frucht-Tiger
2010-08-01, 13:51:05
Schalt mal im Export Fenster "Add Directory Entries" an, das hat bei mir mal einen fiesen Fehler verursacht.

HWT@Work
2010-08-02, 09:59:27
Tut auch nicht, die einzelnen Sachen ins Filesystem exportieren und dann ohne jar direkt die Klasse starten geht aber, irgendwas verhunzt das jar und ich seh es nicht

HWT@Work
2010-08-02, 10:48:43
Ich mache es jetzt so:
-Export to Filesystem (nur der Kram in bin)
-manuell simpelst mögliches jar erzeugen: jar cfv xy.jar *
-starten ohen -jar Anweisung sondern mit java -classpath "Pfad";bal.jar mainXY

Das geht einwandfrei, weiß der Geier, warum das andere nicht

Hardwaretoaster
2010-08-02, 18:16:48
Also wie gesagt, so funktioniert es. Ob das der ideale Weg ist, weiß ich allerdings weiß ich nicht, ob das optimal ist.

Einen gewissen Charme hat es, dass der Classpath notfalls schnell angepasst ist, wenn die Bibliotheken mal wo anders hininstalliert wurden (ich habe die start-Anweisung in einen Batch-Einzeiler gepackt um die Tipparbeit zu sparen).

Berni
2010-08-03, 22:39:45
Da könntest ja mal die jars vergleichen. Sind ja letztlich simple zip-Dateien.

Hardwaretoaster
2010-08-03, 22:48:12
Naja, die MF unterscheidet sich halt, weil in der neuen Variante auch keine Starterklasse definiert ist, aber sonst habe ich nicht viel relevantes gefunden...

BeeRockxs
2010-08-06, 17:28:53
Warum machst du das nicht per ant?