Apache-Ameise - Apache Ant

Apache-Ameise
Apache-Ant-logo.svg
Originalautor(en) James Duncan Davidson
Entwickler Apache Software Foundation
Erstveröffentlichung 19. Juli 2000 ; Vor 21 Jahren ( 2000-07-19 )
Stabile Version
1.10.11 / 13. Juli 2021 ; Vor 2 Monaten ( 2021-07-13 )
Repository Ameisenlager
Geschrieben in Java
Plattform Java-SE
Typ Build-Tool
Lizenz Apache-Lizenz 2.0
Webseite Ameise .apache .org Bearbeiten Sie dies auf Wikidata

Apache Ant ist ein Software-Tool zur Automatisierung von Software-Build- Prozessen, das Anfang 2000 aus dem Apache Tomcat- Projekt als Ersatz für das Make- Build-Tool von Unix entstand. Es ähnelt Make, wird jedoch in Java implementiert und erfordert die Java-Plattform. Im Gegensatz zu Make, das das Makefile-Format verwendet , verwendet Ant XML , um den Codeerstellungsprozess und seine Abhängigkeiten zu beschreiben.

Ant ist ein Open-Source-Projekt, das unter einer Apache-Lizenz der Apache Software Foundation veröffentlicht wurde .

Geschichte

Ant ("Another Neat Tool") wurde von James Duncan Davidson konzipiert , als er die Referenz- JSP- und Servlet- Engine von Sun Microsystems , später Apache Tomcat , für die Veröffentlichung als Open Source vorbereitete . Eine proprietäre Version von Make wurde verwendet, um es auf der Solaris- Plattform aufzubauen , aber in der Open-Source-Welt gab es keine Möglichkeit zu kontrollieren, welche Plattform zum Erstellen von Tomcat verwendet wurde; Daher wurde Ant als einfaches plattformunabhängiges Tool erstellt, um Tomcat aus Direktiven in einer XML-"Build-Datei" zu erstellen. Ant (Version 1.1) wurde am 19. Juli 2000 offiziell als eigenständiges Produkt veröffentlicht.

Es wurden mehrere Vorschläge für eine Ant-Version 2 gemacht, wie AntEater von James Duncan Davidson, Myrmidon von Peter Donald und Mutant von Conor MacNeill, die jedoch keine große Akzeptanz bei der Entwicklergemeinde finden konnten.

Ant war einst (2002) das Build-Tool, das von den meisten Java-Entwicklungsprojekten verwendet wurde. Beispielsweise haben die meisten Open-Source-Java-Entwickler build.xmlDateien mit ihrer Verteilung beigefügt . Da Ant es einfach machte, JUnit- Tests in den Build-Prozess zu integrieren , machte es Ant willigen Entwicklern leicht, testgetriebene Entwicklung und sogar extreme Programmierung zu übernehmen .

Erweiterungen

WOProject-Ant ist nur eines von vielen Beispielen für eine für Ant geschriebene Aufgabenerweiterung. Diese Erweiterungen werden installiert, indem ihre .jarDateien in das libVerzeichnis von ant kopiert werden . Sobald dies erledigt ist, können diese Aufgabenerweiterungen direkt in der typischen build.xmlDatei aufgerufen werden . Die WOProject-Erweiterungen ermöglichen es WebObjects- Entwicklern, ant beim Erstellen ihrer Frameworks und Apps zu verwenden, anstatt die Xcode- Suite von Apple zu verwenden .

Antcontrib bietet eine Sammlung von Aufgaben wie bedingte Anweisungen und Operationen für Eigenschaften sowie andere nützliche Aufgaben.

Ant-contrib.unkrig.deimplementiert Aufgaben und Typen für Netzwerke, Swing- Benutzeroberflächen, JSON- Verarbeitung und andere.

Es gibt andere Aufgabenerweiterungen für Perforce , .NET Framework , EJB und Dateisystemmanipulationen.

Beispiel

Unten ist eine Beispieldatei build.xmlfür eine einfache Java-Anwendung "Hello, world" aufgeführt. Es definiert vier Ziele - clean, clobber, compileund jar, von denen jedes eine zugehörige Beschreibung hat. Das jarZiel listet das compileZiel als Abhängigkeit auf. Dies teilt Ant mit, dass es das jarZiel zuerst vervollständigen muss , bevor es das Ziel starten kann compile. 

<?xml version="1.0"?>
<project name="Hello" default="compile">
    <target name="clean" description="remove intermediate files">
        <delete dir="classes"/>
    </target>
    <target name="clobber" depends="clean" description="remove all artifact files">
        <delete file="hello.jar"/>
    </target>
    <target name="compile" description="compile the Java source code to class files">
        <mkdir dir="classes"/>
        <javac srcdir="." destdir="classes"/>
    </target>
    <target name="jar" depends="compile" description="create a Jar file for the application">
        <jar destfile="hello.jar">
            <fileset dir="classes" includes="**/*.class"/>
            <manifest>
                <attribute name="Main-Class" value="HelloProgram"/>
            </manifest>
        </jar>
    </target>
</project>

Innerhalb jedes Ziels befinden sich die Aktionen, die Ant ausführen muss, um dieses Ziel zu erstellen; diese werden mit integrierten Aufgaben ausgeführt. Um beispielsweise das compile Ziel zu erstellen, muss Ant zuerst ein Verzeichnis namens erstellen classes(was Ant nur tun wird, wenn es noch nicht existiert) und dann den Java-Compiler aufrufen. Daher sind die verwendeten Aufgaben mkdirund javac. Diese führen eine ähnliche Aufgabe aus wie die gleichnamigen Befehlszeilen-Dienstprogramme.

Eine weitere in diesem Beispiel verwendete Aufgabe heißt jar: 

<jar destfile="hello.jar">

Diese Ant-Task hat denselben Namen wie das allgemeine Java-Befehlszeilendienstprogramm JAR, ist aber eigentlich ein Aufruf an die integrierte JAR/ZIP-Dateiunterstützung des Ant-Programms. Dieses Detail ist für die meisten Endbenutzer nicht relevant, die nur das gewünschte JAR mit den angeforderten Dateien erhalten.

Viele Ant-Tasks delegieren ihre Arbeit an externe Programme, entweder native oder Java. Sie verwenden Ants eigene <exec>und <java>Tasks, um die Befehlszeilen einzurichten und alle Details der Zuordnung von den Informationen in der Build-Datei zu den Programmargumenten und der Interpretation des Rückgabewerts zu verarbeiten. Benutzer können sehen, welche Tasks dies tun (zB <csv>, <signjar>, <chmod>, <rpm>), indem sie versuchen, die Task auf einem System ohne das zugrunde liegende Programm im Pfad oder ohne installiertes Java Development Kit (JDK) auszuführen.

Portabilität

Das Ant-Team beabsichtigt, Ant auf allen Systemen zum Laufen zu bringen, auf denen OpenJDK und andere Open-Source- Java-Laufzeiten laufen. Entwickler konzentrieren sich in der Regel auf die Entwicklung für Linux, MacOS, Microsoft Windows und Unix. Ant wurde auch auf vielen anderen Plattformen erfolgreich eingesetzt, darunter OS/2, OpenVMS, Solaris, HP-UX usw.

Eines der Hauptziele von Ant war es, tragbarer zu sein als Make. In Make werden die zum Erstellen eines Ziels erforderlichen Aktionen als plattformspezifische Shell- Befehle angegeben, während Ant eine große Menge integrierter Funktionen bietet, die sich auf allen Plattformen gleich verhalten. In der build.xmlobigen Beispieldatei löscht das saubere Ziel beispielsweise das classesVerzeichnis und alles darin. In einem Makefile würde dies normalerweise mit dem Befehl erfolgen: 

rm -rf classes/

rmist ein Unix- spezifischer Befehl, der in einigen anderen Umgebungen nicht verfügbar ist. Microsoft Windows würde zum Beispiel verwenden: 

rmdir /S /Q classes

In einer Ant-Build-Datei würde das gleiche Ziel mit einem integrierten Befehl erreicht: 

 <delete dir="classes"/>

Außerdem unterscheidet Ant nicht zwischen Schrägstrich oder umgekehrtem Schrägstrich für Verzeichnisse und Semikolon oder Doppelpunkt für Pfadtrennzeichen. Es konvertiert jedes in das entsprechende Symbol für die Plattform, auf der es ausgeführt wird.

Einschränkungen

  • Ant-Build-Dateien, die in XML geschrieben sind , können komplex und ausführlich sein, da sie hierarchisch, teilweise geordnet und durchgängig vernetzt sind. Diese Komplexität kann ein Hindernis für das Lernen sein. Die Build-Dateien großer oder komplexer Projekte können unüberschaubar groß werden. Gutes Design und Modularisierung von Build-Dateien können die Lesbarkeit verbessern, aber nicht unbedingt die Größe reduzieren. Andere Build-Tools wie Gradle oder Maven verwenden prägnante Skripte auf Kosten der Allgemeinheit und Flexibilität.
  • Viele der älteren Aufgaben – die Kernaufgaben, die täglich verwendet werden, wie <javac>, <exec>und – <java>verwenden Standardwerte für Optionen, die nicht mit neueren Versionen der Aufgaben übereinstimmen. Das Ändern dieser Standardeinstellungen würde vorhandene Ant-Skripte zerstören.
  • Beim Erweitern von Eigenschaften in einem String- oder Textelement werden undefinierte Eigenschaften nicht als Fehler ausgegeben, sondern als nicht erweiterter Verweis (zB ${unassigned.property}) belassen .
  • Ant hat begrenzte Regeln zur Fehlerbehandlung.
  • Lazy-Eigenschaftenbewertung wird nicht unterstützt. Wenn Sie beispielsweise in einer Antcontrib- <for>Schleife arbeiten, kann eine Eigenschaft nicht für einen Unterwert neu bewertet werden, der Teil der Iteration sein kann. (Einige Erweiterungen von Drittanbietern erleichtern eine Problemumgehung; AntXtras-Tasksets zur Flusssteuerung ermöglichen eine Cursor-Neudefinition für Schleifen.)
  • In Makefiles kann jede Regel zum Erstellen eines Dateityps aus einem anderen inline in das Makefile geschrieben werden. Beispielsweise kann man ein Dokument in ein anderes Format umwandeln, indem man Regeln verwendet, um ein anderes Werkzeug auszuführen. Das Erstellen einer ähnlichen Aufgabe in Ant ist komplexer: Eine separate Aufgabe muss in Java geschrieben und in die Ant-Build-Datei aufgenommen werden, um dieselbe Art von Funktionalität zu handhaben. Diese Trennung kann jedoch die Lesbarkeit des Ant-Skripts verbessern, indem einige Details der Ausführung einer Aufgabe auf verschiedenen Plattformen ausgeblendet werden.

Es gibt Ant-Erweiterungen von Drittanbietern (genannt antlibs ), die einen Großteil der fehlenden Funktionalität bereitstellen. Außerdem kann die integrierte Entwicklungsumgebung (IDE) von Eclipse Ant-Skripte erstellen und ausführen, während die NetBeans- IDE Ant für ihr internes Build-System verwendet. Da diese beiden IDEs sehr beliebte Entwicklungsplattformen sind, können sie die Verwendung von Ant erheblich vereinfachen. (Als Bonus können von NetBeans generierte Ant-Skripte außerhalb dieser IDE als eigenständige Skripte verwendet werden.)

Siehe auch

Verweise

Weiterlesen

Externe Links