Hier wird für das entsprechende Projekt die Umgebungsvariable CLASSPATH definiert bzw. aktualisiert?
Überschreibt diese Definition die default-Definition von CLASSPATH?
Ist diese Variable eigentlich der Variable vom WINDOWS:Systemsteuerung --> … --> Erweiter-Register --> CLASSPATH ?
Wenn man ohne build-File ein Projekt(das Projekt macht externe jars Gebrauch) kompiliert bzw. ausführt, wo muss man für die CLASSPATH für die externen Jars definieren?
Das, was da in der XML steht, überschreibt nicht direkt die CLASSPATH-Umgebungsvariable, sondern wird nur “intern” verwendet, um den Classpath beim Start “zusammenzubauen”
Der Classpath beim Start kann direkt angegeben werden. Z.B. mit
Windows: java -cp ".;someJar.jar;someOtherJar.jar" TheProgram
Linux: java -cp ".:someJar.jar:someOtherJar.jar" TheProgram
(der Trenner ist bei Windows “;” und bei Linux “:”)
In dem obigen build-File existiert die CLASSPATH-Definition. Beim Kompilieren bzw. Ausführen des Projekts wird also diese CLASSPATH-Definition in Betrach gezogen. Nun ist es meines Wissens nach so, dass in der Eclipse-GUI an sich, man CLASSPATH setzen kann(über Projects --> Properties --> … --> Java Build Path --> Libraries). Überschreibt die CLASSPATH-Definition aus dem Build-File die CLASSPATH-Definition auf der Eclipse-GUI ?
Es ist nicht ganz klar, was du mit “überschreiben” meinst: Das sind ja vollkommen unterschiedliche Pfade. Also, das Compilieren und Starten in Eclipse hat ja nichts mit Ant zu tun (und wird daher auch mit an Wahrscheinlichkeit Grenzender Sicherheit nicht vom Inhalt irgendeiner XML-Datei beeinflusst…)
Also, soweit ich das verstehe sind die zwei Classpaths komplett entkoppelt zu sehen.
Man kann in Eclipse pro Projekt einen Classpath angeben, ja. Und wenn man dann Eclipse kompilieren lässt (Beim Klick auf save wird automatisch kompiliert meine ich), wird dann der Classpath genommen, den man dort im Projekt eingestellt hat.
Je größer ein Projekt wird, desto komplizierter wird so ein Build. Es reicht nicht einfach nur die .java Dateien zu kompilieren so wie es Eclipse macht. Man möchte noch anderes mit reinbringen. z.b einen automatisch hochzählende Build Nummer an dem neu erstellten jar File usw. Dafür wurde dann Ant geschaffen. Und in Ant kann man so etwas machen. Aber der Schritt der in Ant eigentlich immer weit vorne kommt ist ebenfalls das Kompilieren der Sourcen. Und dafür braucht Ant auch einen Classpath.
Ich hätte jetzt gesagt, Ant nutzt nicht den Eclipse Classpath sondern braucht seine eigene Definition. Denn man kann Ant ja auch komplett ohne Eclipse ausführen. Es käme jetzt auf einen Versuch an, die Classpath Definition im Ant Skript wehzulassen und zu gucken ob man das Ant Skript unter Eclipse trotzdem noch starten kann und ob es dann trotzdem noch normal die Sourcen kompiliert. Falls ja, scheint Ant intelligent genug zu sein den Classpath zu finden, der da ist. Falls nicht, scheint Ant zwingend seine eigene Definition zu brauchen.
Was hier vielleicht nicht ganz so deutlich rüberkommt ist, dass man in Eclipse sich ein Ant-Build-Script generieren lassen kann.
File -> Export -> General -> Ant Buildfiles
In diesem Buildscript wird dann auch automatisch ein passender Path gesetzt, so wie er in Eclipse eingestellt wurde.
Man sollte allerdings dies beachten
[XML][/XML]
Das hat den vorteil, dass man das Project aus einem Repository auschecken kann und mit Hilfe von ant bauen, ohne groß ein Eclipse starten zu müssen.
Ändert man allerdings den Path in Eclipse muss man auch das build script neu generieren lassen oder evtl. manuell anpassen.
Das build-script kann man allerdings auch aus Eclipse heraus laufen lassen anstatt den normalen Eclipse-Build.
Allerdings stellt sich die Frage ob Ant wirklich noch so Zeitgemäß ist. Maven (Standart), Gradle und Sbt laufen dem gerade den Rang ab. Oder Leiningen wenn man mit Clojure unterwegs ist.