Ant Targets

From Plex-XML

Development

• compile: Compiliert die aktuell im Projekt vorhandenen Java-Dateien. Muß in der Regel nicht explizit ausgeführt werden, da er von den anderen Tasks bei Bedarf aufgerufen wird.
• plexCopy: Der wahrscheinlich am häufigsten benötigte Task. Dieser Task kopiert alle Java-Dateien aus dem in .ant.properties eingestellten plex.application.home-Verzeichnis (siehe hierzu auch Anpassen des Arbeitsprojektes) in die korrekten Verzeichnisse im aktuellen Projekt.
• plexFunctionCopy: Abgespeckter plexCopy-Task: Kopiert nur die *Fnc- sowie die .resources-Dateien aus dem plex.application.home-Verzeichnis. Kann benutzt werden, wenn keine In- bzw. Out-Parameter geändert wurden, damit die anschließende Compilierung in Eclipse bzw. per ANT (und der Deploy-Prozeß) nicht so lange dauern.
• generate: Generiert mit Hilfe des PleXML-Frameworks für die in .main.properties eingestellte(n) Klasse(n) (Property de.bodow.plex.analyzelist) Bean- und Handler-Dateien. Wird im Regelfall nur für neu erstellte Plex-Funktionen benötigt. Achtung: Der Task kopiert nicht eventuell neu generierte Plex-Funktionen aus dem Plex-Verzeichnis; hierfür muß vorher der plexCopy-Task benutzt werden.
• rebuild: Löscht alle erzeugten Javaklassen und compiliert diese neu.
• updateProject: Aktualisiert Dateien aus dem abhängigen Projekt ACTI-Base, z.B. Basis-XSLTs, Java-Bibliotheken, usw. Sollte nach der Neuanlage eines Projektes sowie nach jedem Update dieser Projekte aus dem CVS ausgeführt werden.

Deployment

• deployLocal: Kopiert alle veränderten Dateien, die zum Deployment notwendig sind, in das lokale Tomcat-Verzeichnis, das in der .ant.properties-Datei (siehe hierzu auch Anpassen des Arbeitsprojektes) eingestellt ist. Hierbei werden die für die Anwendung notwendigen Property-Dateien so verändert, daß sich die Web-Anwendung zur PASSIVE verbinden kann.
• deployPassive: Kopiert alle veränderten Dateien, die zum Deployment notwendig sind, auf den Webserver, der in der .ant.properties-Datei (siehe hierzu auch Anpassen des Arbeitsprojektes) eingestellt ist. Hierbei werden die für die Anwendung notwendigen Property-Dateien so verändert, daß sich die Web-Anwendung zur PASSIVE verbinden kann, wobei als Datenbibliothek im JDBC-Treiber die ACTDTA eingestellt wird. Außerdem werden nur die Standardschnittstellen-Jobs sowie die Financial-Jobs (Währungstransfer) gestartet.
• warActive: Erstellt ein WAR-Archiv (nach dem Build-Prozeß zu finden im build/deploy-Verzeichnis) mit Verbindungsdaten für die ACTIVE (Standarddatenbereich) zum Deployment auf einem Web-Server.
• warPassiveTest: Erstellt ein WAR-Archiv (nach dem Build-Prozeß zu finden im build/deploy-Verzeichnis) mit Verbindungsdaten für die Passive (Finance-Testdatenbereich) zum Deployment auf einem Web-Server.
• warPassiveRST: Erstellt ein WAR-Archiv (nach dem Build-Prozeß zu finden im build/deploy-Verzeichnis) mit Verbindungsdaten für die Passive (Restoredatenbereich) zum Deployment auf einem Web-Server.

Kopiert alle veränderten Dateien, die zum Deployment notwendig sind, auf den Webserver, der in der .ant.properties-Datei (siehe hierzu auch Anpassen des Arbeitsprojektes) eingestellt ist; an den Namen der Web-Applikation wird hierbei automatisch die Endung "RST" angehängt. Die für die Anwendung notwendigen Property-Dateien werden so verändert, daß sich die Web-Anwendung zur PASSIVE verbinden kann, wobei als Datenbibliothek im JDBC-Treiber die RST_ACTDTA eingestellt wird. Außerdem werden nur die Standardschnittstellen-Jobs sowie der Accountbook-Transfer gestartet.

Test

• testApplication: Testet die Konsistenz der aktuellen Applikation mit Hilfe des AppTesters: prüft, ob alle Funktionen aufrufbar sind, ob die XSLTs kompiliert werden können, usw.
• testDifferences: Erstellt eine HTML-Datei mit dem Namen des Projektes im Projektverzeichnis, die die Unterschiede zwischen den aktuellen Javaklassen und den auf dem HAM-APP-3 liegenden Javaklassen auflistet. Dieser Task kann vor dem Deployment benutzt werden, um zu prüfen, was tatsächlich verändert wurde.