jar einfach so übernehmen und ausführen, das geht doch nicht?

1. Das ist dir überlassen ;-)

Nein ernsthaft, das ist wirklich egal, Hauptsache du gibst im Classpath den korrekten Pfad zu den Jars an. Wenn du alle Jars ins gleiche Verzeichnis kopierst, ist die Zusammenstellung des Klassenpfades natürlich sehr einfach, was uns direkt zur nächsten Frage bringt:

2. Abhängig davon, wo deine Jar-Dateien denn nun liegen, gibst du beim Classpath den Pfad zur Jar-Datei entweder absolut (/ewig/langer/dateipfad/zur/jar-datei.jar) oder relativ (./jar-datei.jar) an. Angenommen, du hast alle jars im gleichen (aktuellen Verzeichnis liegen). Und angenommen, deine Main-Klasse liegt im Package-Pfad de.tutorials.classpath_beispiel. Dann sieht ein Shell-Script so aus:

Code: 
CLASSPATH=./de.tutorials.jar:./Hauptprog.jar

export CLASSPATH

java de.tutorials.classpath_beispiel.Hauptprog

Am sichersten ist natürlich die Variante mit dem absoluten Pfad, aber wenn du genau weißt, wo der Kram liegt, gehen auch relative Pfade. Das macht die Sache dann natürlich portabler.

Bei Windows ist es im Übrigen genauso.
 
Hallo saftmeister,

mein externes Jar liegt aber unter Windows unter folgendem Pfad:
C:EclipseWS\src\de\tutorials\ext-jar.jar

Und meine Hauptprog-Klasse liegt unter:
C:\EclipseWS\src\Hauptprog.java

Vielleicht erstmal eine ganz einfache Sache, in dem Programm Hauptprog.java kann folgendes Import geben:

Import de.tutorials.ext-jar.Class-Name

****?
 
Ich glaube, du bringst hier zwei Sachen durcheinander.

Package-Pfad != Klassen-Pfad (Classpath)

- Der Classpath beinhaltet Bibliotheken (Jars) die zur Compile- oder Laufzeit verfügbar sein sollen. Wenn du zur Compile-Zeit ein Jar in den Classpath hinzufügst, und aus dem Jar mittels import eine Klasse in dein eigenes Projekt einbindest, brauchst du das Jar auch im Classpath zur Laufzeit.

- Jede Klasse hat einen Package-Pfad (ggf. auch den default-Package-Pfad). Der zeigt einfach nur an, in welchem Java-Package (nicht JAR-File) die Klasse liegt. Das ist im Grunde der Namensraum, in dem die Klasse existiert. Eine Klasse kann man auch ohne Jar deployen, sie hat dann dennoch einen Package-Pfad. Der Package-Pfad hat den Zweck, Klassen mit unterschiedlicher Funktionalität aber gleichem Klassen-Namen zu ermöglichen (bspw. de.tutorials.Klasse1 => com.google.Klasse1).

Das es möglich sein soll, mittels Angabe des Jars eine Klasse zu importieren, war mir bislang nicht bekannt. Habe es noch nicht ausprobiert, klingt auch ein wenig unlogisch. Das würde bedeuten, ich kann das Library-Jar nicht austauschen, ohne meine Java-Klasse neu kompilieren zu müssen => unportabel.

Vielleicht wäre es ratsam, wenn du dir erstmal angewöhnst, dein Projekt korrekt aufzubauen. Damit meine ich: Libraries gehören NICHT in den src-Ordner. Schau dir mal diese Projekt-Struktur an:

Workspace-Pfad = C:\EclipseWS
Projekt = Test
Libraries = de.tutorials.jar
Main-Klasse = de.ratna.Hauptprogramm

Dann ergibt sich folgende Ordner-Struktur

Code: 
c:\EclipseWS\Test
     |
     |------------- bin
     |                     +-------- de
     |                                    +--------- ratna
     |                                                      +---------- Hauptprogramm.class
     +------------- src
     |                     +-------- de
     |                                    +--------- ratna
     |                                                      +---------- Hauptprogramm.java (hier wird eine Klasse aus de.tutorials.jar importiert)
     +------------- lib
                           +-------- de.tutorials.jar

Eclipse erstellt den bin-Ordner normalerweise automatisch und legt dort die kompilierten Java-Klassen ab (.java => .class).
Wenn du jetzt ein Jar daraus erstellst (was im Grunde ein Zip-File ist), werden die kompilierten Java-Klassen in der Struktur aus dem bin-Ordner in das Archiv komprimiert. Du kannst ja spaßeshalber mal ein .jar-File in Winzip oder 7zip (den Packer deiner Wahl) laden und dir die Ordnerstruktur darin anschauen.
Damit das Importieren von Klassen aus "externen" Jars funktioniert, muss es Eclipse (oder jede andere IDE) die Jars im Classpath haben, sonst hättest du eine unaufgelöste Abhängigkeit.
Und damit du zur Laufzeit keine ClassNotFoundException bekommst, muss die "externe" Library de.tutorials.jar auch im Classpath hinterlegt sein.
Java "entpackt" dann die zu importierenden Klassen (und ihre weiteren Abhängigkeiten) und stellt die darin programmierte Funktionalität bereit.
 
- Der Classpath beinhaltet Bibliotheken (Jars) die zur Compile- oder Laufzeit verfügbar sein sollen. Wenn du zur Compile-Zeit ein Jar in den Classpath hinzufügst, und aus dem Jar mittels import eine Klasse in dein eigenes Projekt einbindest, brauchst du das Jar auch im Classpath zur Laufzeit.
Zum Vergrößern anklicken....

Dann würde die CLASSPATH-Umgebungsvariable so aussehen?

CLASSPATH=./de.tutorials.jar:./de/ratna

Wie kommt man aber von da auf hier:

CLASSPATH=./de.tutorials.jar:./Hauptprog.jar
 
Eclipse-Projekt->Rechte Maustaste->Export... Dort im Assi Java->Jar File und auf Next. Dann im Field "JAR file" den Pfad zur neuen Jar-Datei angeben und auf "Finish"

Das daraus resultierende Jar kannst du dann hinkopieren, wo du es gern hättest.
 
Hallo zusammen,

vielen Dank für Eure Hilfestellungen bisher, hat geklappt und ich habs verstanden.

In dem Projekt ist es so konfiguriert, dass zur Distribution(Jar-Files, Java-Doc, usw..) ein Ant-Build-File Gebrauch gemacht wird. Es ist so, dass bei einer Aktualisierung eines .java-Files man einfach das entsprechende Programm noch mal ausführen tut, NICHT aber das Build-File ausführen. Ist das eigentlich Standard?

Ich dachte immer, wenn man eine Änderung im Code vorgenommen wird, dass das Build-File neu angestoßen werden muss, damit all die Jars, Java-Doc usw. neu erstellt werden. Nun ist es aber nicht so.

Könnt Ihr mir dazu was sagen bitte? Danke schön...

Viele Grüße aus Rheinland,

Eure Ratna:)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück