Your SlideShare is downloading. ×
0
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Lezione 4: I tool Ant e Subversion
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lezione 4: I tool Ant e Subversion

1,701

Published on

✦ Ant …

✦ Ant
✦ Subversion

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,701
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Lezione 20: I tool Ant e Subversion Corso di Ingegneria del Software Laurea Magistrale in Ing. Informatica Università degli Studi di Salerno 1
  • 2. Outline ✦ Ant ✦ Subversion 2
  • 3. Ant ✦ Apache Ant (http://ant.apache.org) è uno strumento per automatizzare la compilazione di programmi Java e task collegati alla compilazione: • creazione di file JAR • esecuzione dei test JUnit • estrazione della documentazione Javadoc • deployment su application server • ... 3
  • 4. Ant vs Make ✦ Gli obiettivi di Ant sono analoghi a quelli svolti da strumenti come Make ✦ Differenze: • Ant è “Pure Java”, portabile su ogni piattaforma • Ant non dipende dalla shell di Unix • Ant è specificamente progettato per programmi Java • Ant è estensibile attraverso la scrittura di classi Java 4
  • 5. Come ottenere Ant ✦ Sito: http://ant.apache.org ✦ Distribuzione binaria per Windows e sistemi Unix-like (incluso Mac OS X) ✦ Incluso in Eclipse • Funzioni di import/export tra progetti Eclipse e file di configurazione di Ant ✦ Nota: la versione a cui faremo riferimento è la 1.7.0 5
  • 6. Ant: concetti fondamentali ✦ La configurazione di Ant viene effettuata attraverso un file XML il cui nome di default è build.xml ✦ Il file di configurazione descrive un progetto ✦ Il progetto può comprendere uno o più target ✦ Un target contiene una sequenza di task 6
  • 7. Ant: concetti fondamentali ✦ All’invocazione (dalla linea di comando) l’utente indica quali target vuole eseguire • ant target... ✦ Se non viene specificato esplicitamente un target, viene eseguito quello che nel file di configurazione è definito come target di default ✦ Ant gestisce le interdipendenze tra i target 7
  • 8. Progetto ✦ L’elemento di livello più alto del file build.xml ha come tag project e i suoi attributi specificano alcuni parametri del progetto • ogni target ha un nome; l’attributo default specifica qual è il target di default <project default="nome"> definizione target 1 definizione target 2 ... </project> 8
  • 9. Target ✦ Un target è definito attraverso l’elemento target, i cui attributi principali sono: • name: nome del target • depends: elenco dei target da cui il target dipende (separati da virgole) ✦ All’interno dell’elemento target sono specificati i task che compongono il target 9
  • 10. Target: esempio <project default="a"> <target name="a"> </target> <target name="b"> </target> <target name="c" depends="a,b"> </target> </project> ✦ In questo caso, il comando: • ant c determina l’esecuzione dei target a, b e c 10
  • 11. Task ✦ Ogni task è rappresentato da un elemento XML • gli attributi specificano i parametri del task • alcuni task hanno richiedono di inserire altri elementi al loro interno ✦ Tre tipi di task: • built-in • opzionali (richiedono la presenza di librerie per essere eseguiti) • esterni (richiedono la presenza di librerie e di apposite definizioni per essere riconosciuti) 11
  • 12. Il task javac ✦ Compila tutti i file .java presenti in una directory (incluse sottodirectory) • la compilazione è effettuata solo se il .java è più recente del .class ✦ Attributi principali: • srcdir: directory dei sorgenti • destdir: directory dei file .class • classpath: classpath da usare nella compilazione ✦ Esempio: <javac srcdir=”src” destdir=”classes” /> 12
  • 13. Il task java ✦ Esegue una classe Java ✦ Attributi principali: • classname: nome della classe • classpath • fork: se true, la classe è eseguita in una nuova JVM • spawn: se true, Ant non aspetta la terminazione dell’esecuzione (richiede fork=”true”) • timeout: time-out in millisecondi per l’esecuzione (solo se fork=”false”, che è il default) 13
  • 14. Esempio: <project default=”build”> <target name=”build”> <javac srcdir=”src” destdir=”classes” /> </target> <target name=”run” depends=”build”> <java classname=”Server” classpath=”classes” fork=”true” spawn=”true” /> </target> </project> 14
  • 15. Il task jar ✦ Crea un archivio in formato .jar per la distribuzione di un programma o di una libreria ✦ I file da includere sono specificati attraverso uno o più elementi fileset ✦ Attributi principali: • destfile: il file .jar da creare • manifest: il file manifesto da inserire come META-INF/MANIFEST.MF (contiene informazioni come la classe da usare per il main, o il class path da usare per l’esecuzione) 15
  • 16. L’elemento fileset ✦ Serve a specificare un insieme di file in base al nome ✦ Attributi principali: • dir: directory da cui estrarre i file (obbligatorio) • includes: pattern dei nomi dei file da includere • excludes: pattern dei nomi dei file da escludere 16
  • 17. L’elemento fileset ✦ Gli attributi includes e excludes specificano dei pattern che possono usare i metacaratteri * e ? • la sequenza speciale ** indica qualsiasi sottodirectory ✦ Se includes non è specificato, si considerano inclusi tutti i file tranne quelli indicati con excludes ✦ Se sono specificati sia includes che excludes, si intendono inclusi tutti i file specificati da includes e non da 17 excludes
  • 18. Esempio ✦ Questo target crea un file .jar usando tutti i file .class tranne quelli delle classi di test <target name=”jar” depends=”build”> <jar destfile=”mylib.jar”> <fileset dir=”classes” includes=”**/*.class” excludes=”**/*Test.class” /> </jar> </target> Nota: Ant riconosce il forward slash per separare le directory anche sotto Windows 18
  • 19. Altri task utili ✦ <mkdir dir=”nome” /> • crea una directory ✦ <echo>testo</echo> • visualizza un messaggio ✦ <mail from=”x” tolist=”y” subject=”z”> <message>testo</message> <attachments> <fileset ...> </attachments> </mail> • invia un’e-mail, eventualmente con allegati 19
  • 20. Properties ✦ È possibile definire variabili, dette properties, con il task property • il task property può essere usato anche al di fuori di un target ✦ Attributi principali: • name • value: valore della property • location: il valore di questo attributo viene trasformato in un pathname assoluto e poi assegnato come valore della property ✦ È possibile usare il valore di una property con la notazione ${propertyName} 20
  • 21. Esempio <project default=”build”> <property name=”src.dir” location=”src” /> <property name=”build.dir” location=”classes” /> <target name=”build”> <javac srcdir=”${src.dir}” destdir=”${build.dir}” /> </target> <target name=”run” depends=”build”> <java classname=”Server” classpath=” ${build.dir}” fork=”true” spawn=”true” /> </target> </project> 21
  • 22. Ant e JUnit ✦ Ant offre due task particolarmente utili per il testing attraverso JUnit: • il task junit lancia gli unit test e salva i risultati in una serie di file (opzionalmente mostrandoli anche sulla console) • il task junitreport produce un rapporto dei test in formato html 22
  • 23. Il task junit ✦ Attributi principali: • fork: se true, i test sono eseguiti in una nuova JVM • timeout: se fork=”true”, indica il time-out in millisecondi per l’esecuzione dei test ✦ I test da eseguire, il classpath e il formato del report vanno specificati con elementi interni 23
  • 24. L’elemento classpath ✦ <classpath path=”...” /> • classpath per l’esecuzione dei test • deve includere la libreria junit 24
  • 25. L’elemento formatter ✦ Specifica il tipo di output ✦ È possibile avere più formatter ✦ Per default salva l’output in un file il cui nome è TEST-ClassName.ext • ext è un’estensione dipendente dal formato ✦ Attributi principali: • type: “brief”, “plain” oppure “xml”; “xml” è necessario per un rapporto in formato HTML • usefile: se “false”, manda l’output sulla console invece che su file; il default è “true” 25
  • 26. L’elemento batchtest ✦ Specifica i file con le classi di test ✦ Attributi principali: • todir: directory in cui sono salvati gli output ✦ I file .java delle classi di test vanno specificati usando degli elementi fileset all’interno di batchtest 26
  • 27. Esempio <property name=”classpath” value=”${build.dir}:lib/junit.jar” /> <target name=”test” depends=”build”> <mkdir dir=”${test.dir}” /> <junit> <classpath path=”${classpath}” /> <formatter type=”brief” usefile=”false” /> <formatter type=”xml” /> <batchtest todir=”${test.dir}”> <fileset dir=”${src.dir}” includes=”**/*Test.java” /> </batchtest> </junit> </target> 27
  • 28. Il task junitreport ✦ Aggrega i risultati degli Unit test in un report in formato HTML ✦ Attributi principali: • todir: directory in cui salvare i file temporanei ✦ All’interno deve essere presente un elemento report con i seguenti attributi: • todir: directory in cui salvare i .html prodotti • format: “frames” (default) oppure “noframes” ✦ I file prodotti dagli unit test devono essere specificati da un fileset interno all’elemento junitreport 28
  • 29. Esempio <target name=”report” depends=”test”> <junit todir=”${test.dir}> <report todir=”${test.dir}” /> <fileset dir=”${test.dir}” includes=”**/TEST-*.xml” /> </junitreport> </target> 29
  • 30. Sistemi di Controllo delle Versioni ✦ Un Sistema di controllo delle versioni (Version Control System, Revision Control System, Source Code Management ...) è un software che gestisce un insieme di file e directory nel corso del tempo • ricorda ogni cambiamento effettuato, e da chi e quando è stato effettuato il cambiamento • è possibile tornare a una qualsiasi versione precedente di ciascun file o confrontare diverse versioni • è possibile combinare i cambiamenti fatti da più utenti per ottenere una nuova versione 30
  • 31. Sistemi di Controllo delle Versioni ✦ Tool fondamentale per la gestione dei sorgenti di un progetto, specialmente se il team di sviluppo è distribuito • tutti i progetti open source di rilievo sono gestiti attraverso un sistema di controllo delle versioni (es. sourceforge) • elimina errori come uso di una versione sbagliata di un file, o perdita irrevocabile di una parte del codice a seguito di una modifica • aumenta il “coraggio” degli sviluppatori, dal momento che ogni modifica può essere facilmente annullata 31
  • 32. Sistemi di Controllo delle Versioni ✦ Alcuni sistemi storicamente significativi • 1972: SCCS ‣ sviluppato prima per mainframe IBM e poi per Unix, richiedeva la condivisione a livello del file system • 1986: CVS ‣ gestione client/server, con disciplina dell’accesso concorrente al repository del codice • 2000: Subversion ‣ versioning a livello delle directory, non più dei singoli file come in CVS; atomic commit; gestione efficiente anche di file binari; oggi è il sistema più usato • oggi: Arch, Monotone, BitKeeper, Git, Bazaar, ... ‣ repository distribuito, non centralizzato 32
  • 33. Subversion (SVN) ✦ Accesso remoto al repository: • tramite tool a linea di comando • tramite client grafici (per Windows: TortoiseSVN) • tramite browser web (sola lettura) • dall’ambiente di sviluppo (es. tramite plugin per Eclipse) 33
  • 34. SVN: concetti fondamentali ✦ Un repository è un albero di directory e file gestito da Subversion ✦ Un repository è identificato attraverso un URL ✦ Di un repository esistono più revisioni, identificate da un numero progressivo; SVN tiene traccia di tutte le revisioni ✦ Il numero di revisione è relativo all’intero repository, non a un singolo file o directory 34
  • 35. SVN: concetti fondamentali ✦ Una revisione viene creata effettuando una serie di modifiche alla revisione precedente; la creazione di una revisione è un’operazione atomica ✦ Gli utenti lavorano su una copia locale (working copy) di una parte del repository, utilizzando il client svn per mantenere la working copy sincronizzata con il repository 35
  • 36. Versione vs revisione ✦ Nell’uso di SVN si usa il termine “revisione” per indicare lo stato dei file nel repository in un determinato istante di tempo; le revisioni sono gestite da SVN ✦ Il termine “versione” indica lo stato di una parte del repository all’atto di un rilascio agli utenti; SVN non gestisce direttamente le versioni, che sono per convenzione mantenute come directory separate del repository 36
  • 37. Struttura del repository ✦ Per convenzione, la directory di un progetto in un repository SVN ha una struttura fissa, contenendo tre sottodirectory: • trunk: directory della versione del progetto su cui si sta correntemente lavorando • tags: directory delle versioni rilasciate del progetto; al momento del rilascio si fa una copia del trunk in una sottodirectory di tags • branches: directory usata per versioni “sperimentali” del progetto, in cui alcuni sviluppatori realizzano e testano soluzioni alternative prima che siano accolte ufficialmente 37
  • 38. Operazioni fondamentali ✦ import • importa un insieme di file e directory all’interno del repository, come sottodirectory della radice del repository • questa operazione NON crea una working copy su cui l’utente può cominciare a lavorare • tipicamente viene fatta una sola volta all’avvio del progetto, per creare la struttura iniziale del repository 38
  • 39. Operazioni fondamentali ✦ checkout • crea una working copy di una parte del repository • copia i file e le cartelle di una specifica revisione (per default, l’ultima) sulla macchina dell’utente, e registra dei metadati che saranno poi usati per sincronizzare la working copy con il repository • di solito viene effettuata la prima volta che l’utente lavora al progetto su una particolare macchina, oppure quando vuole creare una working copy da capo per essere sicuro che non contenga file spuri 39
  • 40. Operazioni fondamentali ✦ add • aggiunge un file o una directory, creati all’interno di una working copy, al controllo di SVN • gli elementi aggiunti non sono immediatamente inviati al repository (vedi: commit) • NOTA: una working copy può contenere anche file che non sono sotto il controllo di SVN, e non sono sincronizzati con il repository • NOTA: è buona norma mantenere nel repository solo i file sorgente (inclusi tutti i file che servono per il build, come il Makefile), non i file da essi derivati (es. eseguibili, file oggetto ecc.) 40
  • 41. Operazioni fondamentali ✦ move, rename, delete • sposta, rinomina o cancella un file controllato da SVN all’interno della working copy • NOTA: queste operazioni vanno fatte tramite SVN, per evitare problemi alla successiva sincronizzazione con il repository 41
  • 42. Operazioni fondamentali ✦ commit • riporta le modifiche effettuate all’interno della working copy sul repository, creando una nuova revisione • registra la data/ora e l’utente che ha eseguito le modifiche, e un commento facoltativo • segnala eventuali conflitti con le modifiche effettuate da altri utenti 42
  • 43. Operazioni fondamentali ✦ update • riporta sulla working copy le ultime modifiche effettuate sul repository, garantendo che la working copy sia allineata all’ultima revisione • segnala eventuali conflitti tra le modifiche effettuate alla working copy e le modifiche effettuate sul repository da altri utenti • NOTA: un commit NON esegue implicitamente un update; perciò è buona norma effettuare esplicitamente questa operazione dopo ogni commit 43
  • 44. Operazioni fondamentali ✦ log • mostra il log delle revisioni per tutto o parte di un repository ✦ revert • annulla le modifiche fatte alla working copy ripristinando la situazione dell’ultimo update ✦ diff • confronta due revisioni di uno stesso file (non binario) evidenziando le differenze 44
  • 45. Gestione dei conflitti ✦ Nelle operazioni di commit o di update può essere scoperto un conflitto tra le modifiche effettuate dall’utente corrente e quelle effettuate da altri utenti • sistemi di controllo delle revisioni precedenti imponevano il “locking” dei file per evitare questi conflitti, riducendo la possibilità di lavorare in parallelo 45
  • 46. Gestione dei conflitti ✦ Per i file di testo (tra cui i file sorgente) SVN cerca di risolvere automaticamente il conflitto: • se i due set di modifiche riguardano parti diverse del file, SVN riesce ad integrare tutte le modifiche nella nuova revisione ✦ Per i file binari, o per parti sovrapposte di file di testo, SVN segnala il problema e richiede che sia l’utente a risolvere manualmente i conflitti prima di accettare la creazione della nuova revisione 46
  • 47. Gestione dei conflitti ✦ In pratica, se tutti gli sviluppatori effettuano frequentemente l’integrazione (e quindi commit/update) i conflitti sui file sorgente sono estremamente rari ✦ NOTA: è considerato assolutamente deprecabile effettuare il commit di una revisione che non compila o non supera tutti i test (a meno che non sia in un branch “privato” di uno sviluppatore) 47

×