Automatiskt byggande med Ant

Transkript

1 Automatiskt byggande med Ant Joakim Beijar Department of Computer Science Åbo Akademi University, FIN Åbo, Finland ACM Klassificering: D.2.9, D.2.6, K.6.3 ACM Special Intrest Groups: SIGSOFT 19 november 2003 Sammanfattning Mjukvaruproduktion är besvärligt, ett stort projekt omfattar hundratals filer och resurser av olika slag som måste kombineras på rätt sätt i rätt ordning. Java har saknat ett robust och användbart bygghanteringssystem för att förenkla byggande som make redan länge utgjort i C/C++ sammanhang. Java ställer egna krav på bygghanteringen men erbjuder också helt unika möjligheter. Denna artikel presenterar kort vad byggande innebär, introducerar läsaren till Ant och visar på de möjligheter som Ant erbjuder Java utvecklare i både små och stora projekt. 1 Introduktion Programutveckling är ett komplext arbete. Redan små program, med en eller ett fåtal utvecklare blir snabbt svåra att hantera och underhålla. När projektet involverar flera utvecklare, flera externa resurser, och utvecklarna är placerade separerat antingen fysiskt eller tidsmässigt blir det omöjligt att kontollera arbetet och det blir svårt att upprätthålla kvaliteten eller hålla satta tidsramar. Vad kan man då göra åt detta? 1.1 Byggande och bygghantering En vanlig lösning på komplexitet är att dela upp problemet i mindre enheter och lösa dem separat. För att kunna göra detta behöver man ett robust sätt att återkombinera alla delar till den fullständiga lösningen efter att man löst dem var och en. Med bygghantering (Build Management) menar man den process och de rutiner man följder för att göra detta i ett mjukvaruprojekt. Traditionellt har byggande omfattat det man gör när man utgående från källkod och andra resurser, kompilerar och sammanlänkar filer på ett sådant sätt att man får en fungerande applikation. Allt oftare involverar processen inte nödvändigtvis kompilerande, många program skrivs i tolkade språk, eller länkning, eftersom detta i många språk sker 1

2 automatiskt vid det tillfälle programmet körs. Allt oftare vill man istället att byggprocessen även producerar annat material, till exempel dokumentation, utför automatiserade tester eller utför konfigurations arbete i databaser. Ett av de första egentliga verktygen för bygghantering var make som presenterades i [Fel79] av S. Feldman redan Make används fortfarande för att bygga majoriteten av alla program som skrivs i C/C++, ingår som standard i de flesta utvecklingspaket i en eller annan form, och är standarden alla andra liknande system jämförs med. I och med Make introducerads också en stor del av de koncept och den terminologi, tex beroenden och mål, som används av många senare verktyg. Make använder sig av en textfil, kallad makefil, för att definiera beroenden mellan de källfiler och de kommandon som används för att bygga ett projekt. Makefilen underhålls manuellt av programmeraren, eller med hjälp av speciella verktyg som försöker bestämma beroenden mellan källkods filerna maskinellt. Den definierar ett antal mål där ett mål i make ofta motsvarar en modul eller ett antal filer som skall behandlas och hur dessa skall behandlas. Varje mål kan vara beroende av ett eller flera andra mål, på så sätt byggs ett träd av beroenden upp som hjälper make att endast återskapa de mål som verkligen påverkas av den ändring som skett sedan senaste körning. 1.2 Release hantering Bygghantering är nära relaterat till releasehantering. Så nära att man ofta talar om dem som en enhet, bygg- och releasehantering. Med en release menar man byggande av en färdig version av applikationen, redo för kund eller slutanvändare. Ofta innefattar releasen steg som inte förekommer i det vanliga byggandet, detta kan vara till exempel paketering och produktion för olika platformar, speciell stress testning, skapande av exempelmaterial och ibland även automatisk installation, så kallad deployment, på en annan maskin. I en release är det också ofta mer kritiskt än under utvecklingsfasen att veta vilka versioner av de olika komponenterna som har ingått för att man senare skall kunna hitta och korrigera fel, dels efterson felsöknings funktionalitet har kopplats bort för att öka prestanda och dels för att det kan gå lång tid mellan att releasen gjorts och felet upptäcks. 2 Vad är ant? Ant är ett Java baserat program för att underlätta, automatisera och strukturera byggande av andra program. Ant underhålls av Apache Foundation som en del i deras Jakarta projekt för att utveckla och underhålla lösningar för Java platformen kostnadsfritt för alla intresserade. Källkoden är fritt tillgänglig och vem som helst kan använda och modifiera programmet enligt sina behov och önskemål. Flexibiliteten att kunna utöka och modifiera programmet är något som ofta är värdefullt när man vill integrera redan existerande system i en organisation. Ant är tänkt att för Java projekt, ta den plats som make har haft i byggandet av C/C++ projekt. Även om det främst är tänkt att användas för att bygga java projekt är det i viss mån även lämpat att bygga program i andra språk eller program där delar skrivs i andra språk. Det sagt är det dock värt att notera att många av de inbyggda funktionerna är väldigt java inriktade och en del av styrkan i Ant kommer ifrån närheten till java miljön. James Duncan Davidson, ants skapare, beskriver i [BBB03] Ant som make without the wrinkles, fritt översatt som make utan, makes rynkor. Som orsak till att han började

3 utveckla ant ger han just dessa ålderna rynkor som gjorde utveckling på flera olika samtidiga platformar besvärligt. Makes stora problem enligt honom var att det var svårt att utöka make på ett återanvändbart portabelt sätt och dess alldeles för stora beroende av den kommandotolk den kördes under, olika platformars tolkar beter sig på olika sätt och hade olika syntax vilket betydde att samma makefil kunde sluta fungera, eller värre fungera på olika sätt när den kördes på olika platformar. Eftersom ant alltid körs i Java tillhandahåller Java en standard miljö som alltid fungerar på samma sätt, oberoende av den underliggande platform det körs på. Ant är inte, och försöker inte vara make i Java. Till exempel ägnar sig ant själv inte åt beroenden mellan individuella filer utan intresserar sig mer för de steg, och den ordning dessa steg skall utföras i för att fullfölja byggandet. Det är upp till de delar som utför dessa steg att kontrollera att filer är aktuella, och återskapa de som inte är aktuella på mest eknomiska och lämpade sätt. Förutom det som make traditionellt använts för kan ant användas till mycket annat, främst tack vare en stor uppsättning funktioner som integrerar andra delar av utvecklingsmiljön. Till exempel finns integration med flera olika versionshanterings system, automatiserad testning, upprätthållande av en källkods stil standard eller automatiserad installation på utvecklingsservrar eller liknande. 3 Kort introduktion till ant 3.1 Anrop och användning I följande anrop utan argument, letar ant efter en build.xml fil i den aktuella mappen och bygger det mål som angetts som utgångsmål i denna. % ant Följande anrop fungerar precis som det tidigare förutom att nu byggs målet allt som definierats i buildfilen annan-build.xml istället. % ant allt -buildfile annan-build.xml 3.2 Buildfilen Kärnan i användandet av ant är en fil kallad buildfilen, buildfilen innehåller en utförlig beskrivning av vad man vill att ant skall göra för att bygga alla delar. Filen är en helt vanlig XML textfil och detta är en fördel av flera orsaker, dels är det lätt att redigera och manipulera utan special verktyg, endast en vanlig text editor är nödvändig, dels undviker man problem med platforms specifika konventioner om radbrytningar eller liknande och sist men inte minst underlättar det maskinell behandling av filen. Ett utvecklingsverktyg kan till exempel enkelt automatiskt generera en buildfil för att bygga ett projekt, och även enkelt underhålla denna under projektets utveckling <project> elementet Buildfilens grundelement är projektelementet som omsluter alla andra element. Projektelementet och dess underelement ger information om projektet som helhet och har följande tre attribut som beskrivs i tabell 1 och ett antal underelement.

4 Attribut name default basedir Beskrivning Frivilligt attribut som anger ett namn för projektet. Egenskapen ant.project reflekterar värdet i detta attribut och kan användas för att infoga projektets namn till exempel för att döpa filer tillhörande projektet. Det mål som används ifall inget speciellt mål har angivits vid anropet. Frivilligt attribut som låter en definiera ett bas från vilken alla relativa sökvägar beräknas från, ifall detta attribut saknas används den sökväg där buildfilen ligger. Tabell 1: Projektelementets attribut Till projekt elementet kan fogas ett frivilligt <description> underelement som ger en beskrivningstext för projektet, detta element påverkar inte byggningen men kan användas av andra program som opererar på build.xml filen, till exempel tredjeparts grafiska gränssnitt. I figur 1 nedan visas exempel på en enkel buildfil med endast ett <project> element, och en beskrivning i <description> elementet. <? xml version =" 1.0 "?> < project name =" exempel " default ="... "> < description > Ett enkelt buildfil exempel. </ description >... </ project > Figur 1: Exempel buildfil 3.3 <target> elementet och beroenden Varje projekt måste ha minst ett, möjligen flera <target> element. Ett av dessa pekas ut av default attributet på projekt elementet. Target elementet har en del attribut som kort beskrivs i tabell 2, dessa styr bland annat hur ant behandlar målet och hur målet kan manipuleras av andra mål. Attribut name depends if unless Beskrivning Definierar ett namn för målet. Lista över andra mål som detta mål är beroende av. Namn på en property som måste vara definierad för att målet skall behandlas. Namn på en property som inte får vara definierad för att målet skall behandlas. description En beskrivning som ges ifall användaren ger argumentet -projecthelp från kommandotolken, mål utan beskrivning tolkas som interna och skrivs inte ut. Tabell 2: Target elementets attribut

5 Varje mål är en gruppering av uppgifter som skall utföras. Man brukar till exempel gruppera alla de uppgifter som behövs för att kompilera källkoden för en modul i ett eget mål och de uppgifter som krävs för att köra automatiska test i ett annat. Vissa mål blir i och med denna gruppering naturligtvis beroende av ett eller flera andra mål. Till exempel måste projektet ha kompilerats för att testerna skall kunna köras, man säger att att paketerings målet är beroende av kompilations målet. Dessa beroenden definierars i depends attributet med hjälp av en komma separerad lista över namn för de mål på vilka det aktuella målet är beroende. Dessa beroenden behandlas av ant från vänster till höger med en djupet först sökning av vart och ett i listan. Till exempel skulle byggning av målet package i buildfilen i figur 2 nedan exekveras i ordningen init, build, test, checkstyle och sist de uppgifter som definieras i målet package. <? xml version =" 1.0 "?> < project name ="... " default =" build ">... <target name =" init "/> <target name =" build " depends =" init "/> <target name =" test " depends =" build "/> <target name =" checkstyle " depends =" build "/> <target name =" package " depends =" build,test, checkstyle "/> </ project > Figur 2: Exempel på beroenden Varje steg utförs endast en gång även om det som build i exemplet, skulle förekomma i överlappande beroenden. Man bör kanske nämna att en byggning inte beöver vara så linjär som det kan verka från exemplet ovan. Till exempel vill man ibland endast kompilera och köra de automatiska test man har skrivit. Detta kan man göra genom ange namnet för det mål man vill bygga, till exempel test som argument vid kommandotolken, eller till exempel genom ett menyalternativ i en grafiskutvecklingsmiljö. Ant kör då endast detta mål och eventuella andra mål som det angivna målet är beroende av. Ibland är det även intressant att kunna på ett mer detaljerat sätt styra ifall ett mål skall behandlas eller inte, till exempel om man vill ta hänsyn speciella egenskaper i den aktuella platformen eller för låta användaren styra byggningen med argument till anropet. Attributen if och unless styr ifall ett viss mål skall behandlas eller ej. Ant avgör detta genom att kontrollera ifall den namngivna egenskapen är definierat eller ej. Målet behandlas alltså endast ifall propertyn namngiven av if attributet är definierat och om egenskapen namngiven av unless attributet inte är definierad. Ifall målet saknar if och/eller unless attribut behandlas det alltid. En egenskap anses definierad ifall den någonstans tidigare (genom ett <property> element eller genom import utifrån) har fått ett värde, ingen hänsyn tas alltså till värdet av egenskapen. Naturligtvis kan både if och unless förekomma samtidigt för ett och samma mål Tasks Tasks är de viktigaste elementen i buildfilen, task elementen i ett mål berättar för ant vilka operationer och i vilken ordning de skall utföras. Ett stort antal tasks för olika ändamål

6 distribueras tillsammans med ant, dessa indelas i två olika uppsättningar, inbyggda och optional. Bland de inbyggda tasksen finns sådana som utför grundläggande operationer som till exempel manipulation av filsystemet (skapa-, radera- och kopiera filer, skapa kataloger osv.), tasks som anropar andra ant buildfiler eller startar helt andra program, manipulerar egenskaper inom ant eller sprider tasks på flera exekveringstrådar. I denna grupp finns även tasks som kompilerar olika källkodsfiler, paketerar filer i olika former eller manipulerar text och XML filer. Bland gruppen optional tasks finns stöd för scriptspråk, olika former av källkodsanalys, integration med olika automatiserade testramverk och versionshanteringssystem. Skulle det råka sig att man behöver göra något som det inte redan finns en inbyggd task är det möjligt att ansluta tasks som skrivits av andra utvecklare eller som man skrivit själv genom taskdef elementet. Det är oftast en bra ide att kontrollera att någon annan inte redan skrivit en task för det man vill göra innan man börjar skriva sin egen, förvånansvärt ofta finns det redan någon annan som skrivit en task för att lösa problemet <property> elementet och properties Properties fungerar som variabler eller konstanter när projektet behandlas, de låter en till exempel definiera sökvägar och namn på ett sätt som gör att de är lätta att underhålla, men kan också användas för att styra hur buildfilen behandlas. Egenskaper tilldelas värden genom att använda den speciella task:en <property> någonstans i buildfilen, <property> tasken tillåts till skillnad från andra tasks även direkt under <project> elementet i vilket fall egenskaper som definieras tilldelas sina värden innan behandlingen av mål inleds. Ett annat sätt att definiera egenskaper är att importera värden antingen från kommandotolkens environment variabler, eller läsas ur speciella property filer. 3.4 Utöka ant Även om ant levereras med en utomordentlig verktygslåda för de flesta tänkbara situationer kan det vara nödvändigt ibland att anpassa existerande tasks eller göra helt nya för att integrera system som redan finns i omgivningen. Ant erbjuder två områden som är tänkta för utökning, tasks och loggare. Genom att skapa nya tasks utökar man den uppsättning av funktioner som ant distribueras med, detta är intressant om man vill ansluta till ett nytt eller ett existerande verktyg som inte stöds av ant, eller om man behöver styra behandlingen på nåt speciellt sätt, till exempel importera egenskaper från en databas. Att utöka tasks är enkelt och uppmuntras aktivt av utvecklarna. Varje ant task är en java klass med klassen org.apache.tools.ant.task som anfader. Ett antal klasser förutom denna är också designade för att användas som bas för utökning, till exempel JDBCTask klassen som är tänkt att fungera som startpunkt för utökningar som har med databaser att göra. Loggare är moduler som bevakar byggprocessen och fångar upp de meddelanden som tasks producerar allt eftersom de arbetar. Ant är från början konfigurerat med ett antal loggare, en standard loggare som skriver meddelanden till konsolen, en loggare som skriver dem till en fil i XML form (perfekt att generera till exempel HTML sidor för intranät sidor) och slutligen en loggare som skickar det samlade resultatet som elektronisk post, till exempel till en e-postlista för utvecklarna. Man kan tänka sig att en organisation kan

7 vilja skriva in resultatet av till exempel test eller källkodsanalys tasksen i en databas för att kunna analysera hur projektet fortskrider. Möjligheterna för utvidgning är i det närmaste obegränsade, fördelen med att utöka med tasks är att det som produceras är platformsoberoende och alla medlemmar i projektet oberoende av den miljö de arbetar i direkt kan dra nytta av dem. Detta till skilland från om man implementerat samma sak i form av script eller binära applikationer där de antagligen krävt omkompilering. Trots detta är det dock värt att minnas att ant är ett bygghanteringssystem först och främst. Vissa saker är enklare och leder till bättre hanterlighet om de implementeras separat, speciellt om de inte direkt har med bygghanteringen att göra. 4 Ant för utvecklaren Även om ant kan användas som en enkel make ersättare för Java är det i situationer när omgivningen är dynamisk som en stabil, täckande, platformsoberoende och gemensam byggmiljö som dessutom kan integreras och anpassas till varierande miljöer verkligen kommer till sin rätt. Att bygga automatiskt innebär förutom inbesparingar i repetitivt och tråkigt arbete även att risken för problem orsakade av slarv eller missförstånd minskar. Efter som alla använder samma verktyg och samma buildfil betyder det att projektet byggs på exakt samma sätt oberoende om man byggt från kommmandotolken, ett IDE eller som del i ett automatiserat byggsystem. Dessutom betyder det att man, med hjälp av versionshantering, kan bygga äldre versioner av projektet på precis samma sätt oberoende av. 4.1 Kompilering och pre-processing Ant stöder i standardutförande förutom den vanliga java kompilatorn javac, som distribueras med Suns JDK även alternativa kompilatorer för java som till exempel Jikes, Symantec s sj eller GNU projektets GCJ. Kompilering av Java Server Pages websidor går också bra att integrera i byggprocessen med hjälp av JspC tasken. Genom ant-contrib 1 projektet har man även möjlighet att kompilera och länka andra språk som C/C++ och Fortran, till exempel om en del av projektet är baserat på dessa språk. Förutom rena språk finns även stöd för ett antal pre-processorer och mallbehandlings program. Just pre-processorer, och malloperationer är bekväma att få med i en automatiserad byggprocess eftersom de ofta kan vara besvärliga att komma ihåg att köra, och köra på samma sätt, om man gjort ändringar i källfilerna. Bland de pre-processorer som stödjs i standardutförande hittar man JavaCC och JJTree, för kompilator utveckling och IContract som stöd för design by contract utveckling. 4.2 Integrering med verktyg Ofta bestämmer man sig inom en organisation för en enda integrerad utvecklingsmiljö (IDE) som alla deltagare i projektet förväntas använda. Styrkan i att använda en IDE för utveckling är att ett program har full koll på alla delar, allt från källkods editor, till felsökning och distribution. För små och koncentrerade team fungerar detta bra men det leder dock till att man bundit hela organisationen till en tillverkare av ett system som 1

8 man har väldigt liten kontroll över, och som dessutom oftast endast finns tillgängligt för en viss platform och ett visst operativsystem. Att bestämma sig för att använda ant som byggplatform betyder att man kan ge eftergifter på de standardiseringar man gör på andra områden. Ant är inte en ersättning för ett IDE, koncentrationen är på att underlätta byggande och de saker som byggandet involverar, inte på att stöda manipulerande av kod, integrerad hjälp eller liknande. Ant kan dock med fördel användas i kombination med ett IDE, integration är dessutom möjlig i flera etablerade och populära IDE:n som till exempel Eclipse 2 eller SunONE 3 och även i ett flertal olika editorer som till exempel GNU/Emacs. Fördelen med detta upplägg är att var och en utvecklare kan använda de verktyg i den miljö som bäst stöder just hans arbete. 4.3 Unit testing Ant kan även hjälpa till att strömlinjeforma testdrivet eller stegvis utvecklande. Testdrivet utvecklande karakteriseras av att utveckling sker en funktion åt gången och av att varje implementering av en ny funktion föregås av att man först skriver en mängd test som skall bekräfta att funktionen fungerar som den bör. När man anser att funktionaliteten är implementerad kompileras modulen och testen utförs, när alla test har passerats utan problem är funktionaliteten komplett och man fortsätter till nästa. Fördelen är att allt eftersom utvecklingen fortskrider visar resultaten av testen dels att allt fungerar var för sig, men också att man under utvecklingen av senare funktionalitet inte omedvetet har gjort val som gör att de ändre delarna av programmet sluatat fungera korrekt. Nackdelen är naturligtvis att utvecklingen blir mer arbetsam i och med att man skriver flera test för varje funktion men och att man dessutom får ett extra steg i sin planera-programmera-komilera-kör cyckel. Genom att integrera testningen i byggprocessen behöver man inte skilt köra testen utan de körs naturligt i samband med att man kompilerar och man ser direkt om man är klar att fortsätta till nästa funktionalitet. För att göra test skrivandet möjligast enkelt, det är trots allt en hel del extra arbete, finns flera ramverk som tillhandahåller grunden för tests och ett sätt att utföra testen automatiskt. Ant stöder i standardutförande tester skrivna för JUnit ramverket men kan som bekant byggas ut för att stöda även andra. JUnit var det första populära ramverket för Java testning, och är nu beprövat, populärt och i det närmaste standard. 5 Centraliserat byggande Hittils har byggandet främst behandlats som nåt som äger rum på varje utvecklares arbetsstation och flera gånger per dag, till och med per timme under utvecklingsprocessen. En stor del av de funktioner som ant erbjuder är speciellt lämpade för centraliserat byggande eller som ett sorts Software Configuration Manangenet system enligt hur J. Estublier beskriver ett sådant i [Est00]. Centraliserat byggande är en rutin där hela projektet allt eftersom arbetet fortskrider byggs på en central server, till exempel varje natt efter att alla utvecklare checkat in sina updateringar för dagen eller till och med oftare, varje gång en ändring har checkats in. 2 Eclipse Integrated Developers Environment 3

9 En dylik rutin hjälper att snabbt fånga upp problem som kan uppstå vid integrering och samtidigt tillhandahålla kontinuerligt en updaterad version av projektet till för testning och evaluering. Ant kan användas för att skapa ett helt automatiserat centralt byggsystem som hämtar källkod från källkodslagret, bygger, testar, analyserar produkten och rapporterar problem och status på ett antal olika möjliga sätt. 5.1 Versionshantering Iden i versionshantering är enkel, varje gång en fil sparas skapas en ny version av filen. På så sätt skapas en komplett historik över de ändringar som gjorts i filen och det blir möjligt att gå tillbaka och återställa, eller bara visa, filen som den var vid en tidigare tidpunkt, helt eller delvis. Att kunna återställa äldre versioner av filer är speciellt värdefullt i mjukvaruutveckling eftersom det gör det möjligt att jämföra den källkod som använts för att skapa olika versioner av en applikation till exempel för att få reda på när ett visst beteende introducerats. Det gör också riskerna med att omstrukturera koden mindre eftersom man alltid har möjlighet att återställa koden till det läge den var tidigare. Många versionshanteringsssytem låter en dessutom underhålla parallela versioner vilket betyder att man kan fortsätta att underhålla äldre versioner av koden, även om man gjort stora förändringar i en nyare version. Versionshanteringen gör det också möjligt att hålla reda på när och vilken utvecklare som bidragit med vilken del av koden, ner till enstakt kod rader. Detta ger naturligtvis en möjlighet att samla statistik och ge bättre underlag för att veta var i teamet det behövs mer skolning eller uppföljning. Ant integrerat med ett stort antal versionshanteringssytem både komersiella som Rational ClearCase, Microsoft SourceSafe och OpenSource verktyg som CVS och Subversion gör det möjligt att i en central byggning uppsättning alltid arbeta med den senaste versionen av materialet i projektet utan att någon manuellt behöver ingripa. 5.2 Källkodsanalys och standard Det är ofta som del i ett uppföljnings och lägeskonstroll rutiner viktigt att kunna göra kontinuerlig analys material i projektet. Man beräknar olika sorters statistik för källkoden i projektet till exempel för att upptäcka funktioner som bör splittras i mindre delar för att öka läsbarheten, funktioner med hög komplexitet, eller helt enkelt som ett enkelt mått på hur arbetet fortskrider. Den centrala byggprocessen är klart det lämpligaste stället att utföra dessa test på. Detta främst eftersom det ofta tar tid att utföra dessa beräkningar och det skulle störa flödet i utvecklingsarbetet, men också eftersom varje utvecklare ofta endast har tillgång till de delar som denne för tillfället arbetar med och därför inte kan ge en bra helhets bild. Program som Checkstyle 4 integrerar med ant i byggprocessen för att varna för ett stort antal farliga konstruktioner och orsaker till dålig läsbarhet. Många av dessa farliga konstruktioner fångas inte upp av kompilatorn eftersom de inte är syntaktiskt felaktiga utan endast logiska och ofta leder till problem som är svåra att diagnostisera. Förutom att analysera koden kan CheckStyle användas för att upprätthålla rent stilmässiga regler eller en enhetlig kodstandard för en organisation. Man kan till exem- 4

10 pel bestämma att variabler och klasser skall döpas enligt vissa regler, kontrollera att källkodsfiler uppfyller olika sorters storleks ramar, att koden kommentarats tillräckligt, och att dessa finns på rätta ställen. 5.3 Packetering och installation När Java program kompileras producerar kompilatorn en skild så kallad.class fil för varje klass i applikationen. Eftersom detta snabbt blir besvärligt att underhålla och hantera på grund av det stora antalet filer och kataloger som krävs burkar man packetera ihop alla klassfiler tillsammans i ett så kallat JAR arkiv. En JAR fil innehåller alla de klasser och kataloger som krävs för att representera en applikation eller ett funktionsbibliotek. En jar kan också fungera som en exekverbar enhet. I sådana fall innehåller JAR filen också extra information om den klass fil som skall användas som startpunkt för applikationen samt annan information om applikationen. Eftersom detta paketeringsarbete är en så central del i skapandet av en java applikation innehåller Ant även en rad tasks för att bygga JAR filer och även andra sorters arkiv. För att förenkla skapandet av speciella JAR filer, WAR filer, som används för att paketera servlets, java program som fungerar som del i webapplikationer, finns även en speciell task. När alla paket är skapade blir det också intressant att automatiskt kunna distribuera dessa på olika vis, och eventuellt även att automatiskt installera dem på olika sätt och i olika konfigurationer. Ren distribution är möjlig genom till exempel <copy> tasken som förutom för att kopiera inom det lokala filsystemet också kan användas för att kopiera till delade skivor eller genom WebDAV över internet till en server någon annanstans, om detta inte är möjligt eller lämpligt finns även möjlighet att använda FTP för överföring. För mer avancerad installation (deployment) av till exempel webbapplikationer i Enterprise Java Beans miljö finns stöd för ett flertal populära servrar. Ofta distribueras installations tasks även av den tillverkare som skapat servern. 6 Konklusion Allt detta är dock inte helt utan problem och begränsnignar. I [Lou02] tar Steve Loughran upp ett antal av dessa, vissa är problem i Ant andra är problem som uppstår ur den platform Ant baserats på. Bland andra nämns att stora projekt förblir komplicerade, oberoende av Ant eller vilket bygghantering system som helst. Alla projekt behöver fortfarande någom som kan hålla koll på vilka delar som är beroende av vilka andra, man behöver fortfarande en sund plan för hur projektet skall styras och någon måste vara ansvarig och ha kontroll över utvecklingen. En annan punkt som tas upp är det faktum att man forfarande behöver alla de delar som annars ingår i ett strukturerat byggande, till exempel versionshantering och nåt sätt att följa upp felrapporter. Utan dessa spelar ant ingen roll, Ant fungerar endast som en knutpunkt för andra delar i byggprocessen och bidrar egentligen inte med något konkret, endast styrning. Detta är både en nackdel of fördel, jämfört med helt integrerade system är en Ant baserad miljö mer komplicerad och arbetsdryg att underhålla eftersom ett stort antal olika program måste interagera med varandra. Men det är även en fördel eftersom man då kan välja de verktyg som är mest lämpliga för situationen ur funktionalitet och kostnadssynvinkel, en del kan också bytas ut utan att nödvändigtvis påverka de andra.

11 Ant hjälper till att förenkla de tråkiga delarna av mjukvaruutveckling genom att på ett stabilt och portabelt sätt automatisera dem. På så vis kan Ant också hjälpa till att återskapa en del av det roliga i arbetet från det mekaniskt och tråkiga och byrokratiska vi ibland tvingas utstå. Referenser [BBB03] Stephane Bailliez, Nicola Ken Barozzi, and Jacques Bergeron. Apache Ant User Manual. The Apache Software Foundation, [Est00] [Fel79] Jacky Estublier. Software configuration management: a roadmap. In Proceedings of the conference on The future of Software engineering, pages ACM Press, Stuart I. Feldman. Make-a program for maintaining computer programs. Software - Practice and Experience, 9(4):255 65, [Lou02] Steve Loughran. Ant in anger. in anger.html, 2002.