[DEV] ant

[greiol]

Ist bei den Windows eclipse Versionen eigentlich auch ant dabei? Falls ja, könnte bitte mal einer der Windows Entwickler ausprobieren, ob die build.xml auch unter Windows sauber durchläuft?

 

[pfeffer]

wow!

ich habe keine Ahnung von Ant.
Habe folgendes probiert:
Project/Properties/Builders/New/Browse Workspace/<selected build.xml>/OK

Danach:
Run/external tools/Cachwolf build.xml

Dann kommt ein großartiger Dialog, in dem man auswählen kann, für welche Plattformen man bauen will (ich habe die Voreinstellung <all pülatforms> belassen), und dann erhalte ich folgende Ausgabe :-(

Buildfile: C:\Dokumente und Einstellungen\r\Eigene Dateien\programmieren\elcipse\workspace\cachewolf\build.xml

BUILD FAILED
C:\Dokumente und Einstellungen\r\Eigene Dateien\programmieren\elcipse\workspace\cachewolf\build.xml:22: pleasy specify property ewecl.exe Hint: -Dewecl.exe=/path/to/ewecl

Total time: 219 milliseconds

Gruß,
Pfeffer.

 

[greiol]

ja ja, die geocacher

pleasy specify property ewecl.exe Hint: -Dewecl.exe=/path/to/ewecl

wenn man den hint nicht rot13 kodiert, sehen sie ihn nicht

die property ewecl.exe ist noch nicht definiert. wenn man ant auf der command line aufruft geht das mit -D bzw. eclipse bietet dafür in den run settings für das ant/script eine möglichkeit die properties zu setzen.

 

[pfeffer]

ich habe ihn schon gelesen, aber ich wusste nicht, was eine Property ist und wie ich die setzen kann. Außerdem: ewecl sollte doch im program-Verzeichnis liegen (wenn nicht, dort hinzufügen), so dass die property doch schon im .xml gesetzt werden könnte, oder?


Gruß,
Pfeffer.

 

[greiol]

ich habe den pfad zur ewecl.exe deshalb nicht hat eingetragen, weil diese nicht im svn ist und ich dem entsprechend nicht weiss wo der user sie tatsächlich installiert hat. die position der ewecl taucht derzeit in den "cachewolf selber bauen" anleitungen nicht auf.

 

[MiK]

Ist die wirklich nicht im SVN? Ich dachte das wurde mal alles hinzugefügt.

 

[greiol]

nope. ist nicht drin. müsste ja ohnehin os spezifisch abgelegt werden. und der weg über

java -cp lib/ewe.jar Ewe programs/jewel.ewe -c file.jnf

produziert (zumindest bei mir) unter linux jar files die nicht funktionieren weil teile fehlen - die diskussion hatten wir ja etwas weiter unten. deshalb bin ich ja zurück zur ewecl. falls mir jemand einen codeschnipsel liefern kann wie ich den weg über java so modifizieren kann, dass es läuft, baue ich das gerne um/ein.

 

[pfeffer]

ahh - ok, jetzt verstehe ich erst Deine Probleme, die Du früher schonmal angesprochen hattest...

Das ist ja sehr seltsam, schließlich werden genau so die Nightly Builds (und zwar unter Linux) gebaut, die ja offensichtlich funktionieren. Oder funzt das .jar von dort bei Dir auch nicht?

Sollen wir lieber in dem alten Thread über die Lösung dieses Problems diskutieren?

Gruß,
Pfeffer.

 

[MiK]

Das ist ja sehr seltsam, schließlich werden genau so die Nightly Builds (und zwar unter Linux) gebaut, die ja offensichtlich funktionieren.

Eben nicht. Diese Jars werden über fwrtsnapshot.sh mit ewecl erstellt.

 

[pfeffer]

ahh - jetz ja.

na dann sollte ewecl und ewecl.exe in programs und im ANT-file es entsprechend plattformabhängig aufgerufen werden.

Gruß,
Pfeffer.

PS: heißt das, dass jewel.ewe einen Bug hat?

 

[greiol]

ah, ich dachte das problem sei bekannt und bloss nicht sauber dokumentiert, weil es in fwrtsnapshot ja "umgangen" wurde.

für linux könnte ich die ewecl hochladen, für windows habe ich bisher nur eine ewe.exe gefunden. falls ich die ewecl.exe übersehen habe, wäre es nett wenn ein windows entwickler die entsprechende version hochladen würde. oder falls sich unter windows mit dem java aufruf brauchbare JARs generieren lassen wäre das auch eine lösung.

startet ewe.exe auch die gui wenn man es komplett mit commandline parametern für den build füttert? ich habe noch nie versucht aus ant heraus etwas zu starten was eine gui nachlädt. aber einen evrsuch wäre es wert.

eine angepasste build.xml könnte ich heute abend hochladen und falls es klappt, könnten wir ein paar der .sh und .bat scripte in rente schicken und aus einem einzigen script heraus bauen.

 

[pfeffer]

die ewecl wurde verwendet, weil auf dem Rechner, auf dem das Skript lief, kein java drauf war.

wo ist eigentlich die ewecl zu finden - habe sie auf die schnelle auf ewesoft.com nicht gefunden.

könnte es sein, dass das Problem, dass bei dem Java-Aufruf manche Dateien fehlen, mit Problemen mit relativen Pfaden zusammenhängt? - Ist die Antwort "nein" richtig, weil die Exen korrekt gebaut werden?

Gruß,
Pfeffer.

 

[greiol]

die ewecl gibt es scheinbar nur im linux paket, vermutlich um einen headless betrieb zu gewährleisten. zumindest die gtk2 version gibt unter linux beim reinen parameter betrieb aber auch nur informationen auf der console aus. sofern die windows version sich genauso benimmt, sollte das also kein problem darstellen.

da ewe(cl) keine .java in .class umwandelt sondern nur paketiert, braucht man den java compiler zusätzlich - so funktioniert derzeit auch fwrtsnapshot.sh.

EXEs habe ich ehrlich gesagt noch nicht getestet. rein egoistisch ging es mir erst mal darum die JARs zu haben die ich auch benutze

 

[pfeffer]

ahh - jetz erinnere ich mich: die java-jewel-Variante gibt zwar nichts auf der GUI aus, wenn man sie mit Parameter "-c" startet, aber sie vermisst sie trotzdem, weshalb es auf den NightlyBuild-Servern so nicht geht.

Ohh Mann, wäre mein Gedächtnis nur besser...

Gruß,
Pfeffer.

 

[greiol]

ich habe mal eine kleine vergleichsreihe gemacht (siehe anhang). egal welche java version ich nehme die erzeugten JARs sind immer gleich gross. egal welche ewe version ich nehme, die erzeugten JARs sind immer gleich gross. Nur der größenvergleich der JARs zwischen ewe und java, zeigt einen unterschied.

die übrigen versionen scheinen nicht betroffen.

bis das geklärt ist, sollten wir vermutlich beim build mit ewe(cl) bleiben um JARs zu erzeugen.

 

[greiol]

neue build.xml eingecheckt

 

[pfeffer]

jetzt bekomme ich

Buildfile: C:\Dokumente und Einstellungen\r\Eigene Dateien\programmieren\elcipse\workspace\cachewolf\build.xml
clean:
   [delete] Deleting directory C:\Dokumente und Einstellungen\r\Eigene Dateien\programmieren\elcipse\workspace\cachewolf\bin
fixreleasenumber:
     [echo] setting build version: 20090311
     [echo] setting build type: 3
compile:
    [mkdir] Created dir: C:\Dokumente und Einstellungen\r\Eigene Dateien\programmieren\elcipse\workspace\cachewolf\bin
    [javac] Compiling 128 source files to C:\Dokumente und Einstellungen\r\Eigene Dateien\programmieren\elcipse\workspace\cachewolf\bin

BUILD FAILED
C:\Dokumente und Einstellungen\r\Eigene Dateien\programmieren\elcipse\workspace\cachewolf\build.xml:188: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "C:\Programme\Java\jre1.6.0_07"

Total time: 2 seconds

In C:\Programme\Java\jre1.6.0_07 befindet sich tatsächlich kein javac, dafür ein Verzeichnis "bin", unter dem ich javac vermuten würde, aber auch da findet sich nur eine java.exe. - ok liegt vermutlich daran, dass es ein jre und kein jdk ist?
sehr seltsam: eine suche unter c:\propgramme nach javac ergab keine passenden Treffer. Wie compiliert eclipse?

Gruß,
Pfeffer.

BTW: der tolle Auswahl-Dialog mit den unterschiedlichen Zielen erscheint bei mir nicht mehr :-(

 

[greiol]

javac & ant:
mal sehen wie ant bestimmt welchen java compiler es nehmen soll. hmm.

auswahl des target:
eclipse "merkt" sich deine letze auswahl. zum ändern wirst du vermutlich auf die build.xml rechtsklicken müssen und dann bei den properties die run/debug settings anpassen

eclipse java:
unter Window / Preferences / Java / Installed JREs findet sich bei mir eine Liste der Java Umgebungen die eclipse benutzen kann. das muss sich nicht zwingend mit dem pfad decken.

 

[MiK]

Lässt sich dieses neue Buildsystem dann nur mit Eclipse aufrufen, oder funktioniert es auch auf der Commandline ohne Eclipse installieren zu müssen?

 

[greiol]

ehrlich gesagt war die möglichkeit es aus eclipse heraus aufrufen zu können für mich nur ein angenehmer nebeneffekt.

es funktioniert auch wenn man ant über die kommandozeile aufruft. sofern dort wo der java interpreter liegt mit dem ant aufgerufen auch ein java compiler liegt - bzw. man die parameter richtig setzt.

für einen "richtigen" build sollte man ohnehin noch zwei properties setzen.

-Dbuild.type=X

wobei 0<=X<=3 wie in Version.java VERSION_TYPES definiert sein kann (default ist 3) und

-Dbuild.version=X

wobei X durch die aktuelle svn repository version ersetzt werden muss. default ist derzeit das aktuelle datum(YYYYMMDD), was noch eine ganze weile von der svn version abweichen dürfte, aber für einen testbuild ausreicht.

die svn informationen muss man entweder mit einem svn commandline client ermitteln (plattformabhängig) oder man müsste die installation der ant svn extensions voraussetzen, was aber für einen einfachen test etwas zu viel des guten sein dürfte.

wenn wir an der stelle sind, könnte man noch überlegen ob man vom aufruf

svn info

und herausgreppen der Revision in fwrtsnapshot.sh zum aufruf

svnversion

wechselt.

der vorteil des zweiten aufrufs ist, dass man nur genau einen wert als antwort bekommt und nicht greppen muss. ausserdem wird auch noch ermittelt ob die lokale kopie modifikationen gegenüber dem hauptrepository enthält. das könnte man vorher abfangen und eine syncronisation einleiten oder warten bis man beim compilieren auf die nase fällt weil die versionsnummer bei lokalen änderungen nicht mehr rein numerisch ist

als letztes könnte man dann noch in Version.java (egal was man nun zum build benutzt) direkt die zeile

static final int SVN_REVISION =

mit einem sinnvollen wert füllen (das ant script macht das schon so), statt den umweg über die zeile

static final String VER_SVN =

zu gehen, denn der trick der da ursprünglich versucht wurde, klappt ja eh nicht und bringt so nur eine unnötige konvertierung mit.