Re: [ant] "build-Design"

Hallo Ingo

"Ingo R. Homann" <ihomann_spam@xxxxxx> schrieb im Newsbeitrag
news:433bd653$0$26203$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi,
>
> Daniel Rohe wrote:
[...]
> Ich hatte das zugegebenermaßen verkürzt dargestellt.
>
> Das Problem ist folgendes: Wenn Eclipse P compiliert, weiss Eclipse zwar,
> dass A davon abhängt, aber ich (genauer: tomcat) braucht ja P.jar ja im
> A-Verzeichnis, also genauer unter ${A}/WEB-INF/lib. Jetzt ist es so, dass
> im A-build ein Task steht, der sich das aktuelle P.jar holt, aber dieser
> Task muss ja erstmal irgendwie aufgerufen werden. Und das kann ich nicht
> beim builden von A machen, weil A ja auch manchmal gebuildet wird, ohne
> dass P gebuildet wird, und dann wäre es übertriebener Aufwand. Daher ist
> es so, dass (Hack!) der P-build den A-build aufruft, ihn also hinweist:
> "Es ist ein neues P.jar da.".

Wann erstellst du das P.jar? Bestimmt nicht nach jeder Änderung im
Quellcode! Ein Archiv, mit dem in einem anderen Projekt weitergearbeitet
wird, würde ich nicht automatisch mit jeder Codeänderung erstellen, sondern
erst nachdem alle Tests erfolgreich waren.

> Oder soll ich es so machen, dass der A-build immer nachguckt, ob ein
> aktuellers P.jar vorliegt und es sich nur dann rüberkopiert?

Vom Verständnis der Abhängigkeiten wäre ich für die zweite Variante. Dabei
ist der copy-Task von Ant auch eine Hilfe: "By default, files are only
copied if the source file is newer than the destination file, or when the
destination file does not exist." Somit wird nur kopiert wenn wirklich ne
Änderung an P.jar war.

[...]
>> sollte die Builddatei auch ohne
>> Eclipse funktionieren.
>
> Klar! Das tuts natürlich auch. Allerdings gibt es eben (zusätzlich) ein
> paar Eclipse-spezifische Tasks in der build.xml, die von Eclipse beim
> build aufgerufen werden.

Hier hab ich mal ne Frage: Verwendest du den Ant-Builder
(Projekt-Properties) oder startest du Ant über eine Launchkonfiguration
(Button in der Toolbar)?

Hier würde ich auch überlegen, ob ich die Eclipse-spezifischen Targets
auslagere und dann in das normale Build über Entity-Refs importiere oder von
der Eclipse-spezifischen Builddatei die normale Builddatei aufrufe. Da kommt
es auf die Komplexität an, wie die Eclipse-spezifischen Targets und die
normalen Targets interagieren.

>
> > Das automatische Kompilieren, was Eclipse macht,
>> verwende ich nur für die Entwicklung (Code Completion, Method Suggestion,
>> etc.),
>
> Ja, ausser....
>
> > die dabei entstandenen Programmdateien werden nicht weiterverwendet,
>> deswegen können die alle in dem Standardverzeichnis ("bin") liegen.
>
> ...nee! Ich will eben möglichst einfach und komfortabel in Eclipse eine
> Klasse ändern, und der laufende Tomcat läd die (wenn es keine größeren
> Änderungen an der Klassenstruktur sind, sondern nur Code-Änderungen)
> automatisch nach. Das funktioniert momentan soweit auch sehr gut, der
> gesamte Prozess vom "Abspeichern der .java-Datei" über "Compilieren zur
> .class-Datei" bis zu "tomcat hat die Klasse geladen" dauert
> schätzungsweise 1 sec. Das ist optimal, und da will ich keineswegs von ab
> kommen.

Also hier aus Zeitgründen dann doch den Eclipse-Compiler direkt ins
WEB-INF/classes kompilieren lassen. Das lässt sich aber auch gut über den
Ant-Builder in Eclipse integrieren (Targets -> Auto Build) dabei würde ich
dann gleich den Sun-Compiler anstoßen und die Java-Datei damit kompilieren
und in das Webverzeichnis WEB-INF/classes packen.

[...]
> Mal nebenbei: Wie führst Du sinnvoll UnitTests auf dem Tomcat aus? (Das
> ist sicher ein ganz neuer Thread...) Führt der JUnittest einfach einen
> HttpRequest auf eine festcodierte URL aus, oder kannst Du da (mit
> irgendeiner API) sagen "clicke bitte den 3. Link an, fülle in der neuen
> Seite jenes Formular aus, clicke auf submit und überprüfe, ob die
> gelieferte Seite keine Fehlermeldung enthält"?

Da würde ich HttpUnit (http://httpunit.sourceforge.net/) oder Cactus
(http://jakarta.apache.org/cactus/index.html) verwenden. Innerhalb der
Testmethode wird der UseCase getestet, d.h. der Request wird vorbereitet und
die erste Url aufgerufen, dann das Ergebnis verarbeitet (HttpResponse), die
Form gefüllt und abgesendet usw.

>
>> Was willst du hier mit Tomcat machen? Willst du testen (ohne oder mit
>> Tomcat) oder debuggen?
>
> Beides. Momentan ist es so konfiguriert, dass die Applikation vollständig
> von Eclipse aus mit tomcat gestartet werden kann und ich theoretisch
> produktiv mit arbeiten könnte.
>
> > Wieso lässt du den Tomcat (mit aktiviertem JPDA)
>> nicht ständig laufen und aktualisierst das Webverzeichnis?
>
> Ich weiss zwar nicht, was JPDA ist (der Debugger?), aber im Prinzip hatte
> ich doch beschrieben das ich genau das mache (also das "ständig laufen und
> aktualisierst das Webverzeichnis").

JPDA = Java Platform Debugger Architecture

Dass verwende ich vor allem zum Remote-Debuggen von Webanwendungen. Also
auch wenn die Webanwendung auf einem entfernten Tomcat mit aktiviertem JPDA
ist, kann ich vorausgesetzt der Quellcode bei mir auf dem Rechner ist
gleich, diese debuggen. Das geht auch mit einem lokalen Tomcat und ich finde
diese Art besser als irgendein Plugin in Eclipse zum managen einer
Tomcat-Instanz zu verwenden.

[...]
> Das ist schon klar. Theoretisch könnte ich sogar A.jar als Programm-JAR
> angeben, und P.jar als Library-JAR, dann würde P.jar gar nicht obfuscated
> werden.
>
> Aber es geht ja um das genaue Gegenteil: Ich habe ein A.jar und ein B.jar,
> und *beide* sollen obfuscated werden. Das geht mit proguard nicht
> (zumindest nicht, wenn man es nicht relativ umständlich über
> "inkrementelle obfuscation" machen will, was ich noch nicht getestet
> habe). Oder übersehe ich was?

Hab mal kurz die Doku zu ProGuard überflogen. Da steht man kann als Input
auch WARs verwenden oder mehrere Input-Jars und ein Output-Jar festlegen.
Schau dir mal den folgenden Link an
http://proguard.sourceforge.net/manual/usage.html#filters, vielleicht hilft
das auch weiter.

Freundliche Grüße
Daniel


.

Quantcast