Il documento descrive l'uso di Apache Ant e Subversion (SVN) per la gestione di progetti di ingegneria del software. Ant è uno strumento per automatizzare la compilazione di programmi Java e gestire attività correlate, mentre SVN è un sistema di controllo delle versioni che consente di gestire e tracciare le modifiche apportate ai file di progetto. Vengono forniti dettagli su come configurare Ant tramite file XML e sulle operazioni fondamentali di SVN per gestire le versioni e le revisioni del codice.

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