MTAPO - LABORATOR 1

SCOP:
Familiarizarea cu instrumentele şi mediile de lucru ale laboratoarelor, temelor de casă, proiectului la
disciplina MTAPO.
1. Eclipse
2. Ant
3. Sisteme pentru controlul versiunilor

1. Eclipse
IDE-ul folosit – Eclipse (Eclipse Juno). Vom folosi IDE-ul Eclipse IDE for Java EE (Enterprise Edition)
Developers atât pentru aplicaţiile Java (aplicaţii multi-nivel), cât şi pentru cele C/C++ (vezi).
JDK-ul (care trebuie instalat primul) se poate obtine de aici (Java SE Runtime Environment 8u101).

2. Ant
Ant este un build tool (de la Apache Software Foundation) pentru Java, similar GNU make-ului. Oferă
portabilitate, este simplu de utilizat, fiind independent de platformă sau de mediul de dezvoltare. Spre
deosebire de un makefile, în care se scriu comenzi specifice platformei respective, un fişier Ant este un
document XML care conţine comenzi generice, nefiind necesară rescrierea lui la portarea pe alt sistem.
Rularea se face executând ant în linia de comandă, în acelaşi mod în care se apelează make.
Documentaţia complete o găsiţi în manualul Ant.

Aceasta va fi modalitatea de compilare şi rulare a laboratoarelor, temelor de casă şi a proiectelor.

Arhivele temelor vor conţine, obligatoriu, fisierul build.xml, şi, de asemenea, o structură organizată pe
directoare.

Pentru instalare, dezarhivaţi şi realizaţi următoarele setari:

 variabila de mediu ANT_HOME trebuie să indice directorul în care s-a facut dezarhivarea
 variabila de mediu PATH trebuie să conţină directorul bin al kit-ului. Exemplu:
%ANT_HOME%\bin pe Windows, $ANT_HOME/bin pe Linux

Exemplu de fişier build.xml:

Observăm:
 elementul top-level al documentului este project
 elementul target permite definirea diferitelor activităţi, în cazul nostru: compilare, rulare,
curăţare:
 o implicit, la un simplu apel ant, se execută target-ul specificat de atributul default al
elementului project (in cazul nostru, run)
o dacă se doreşte executarea unui target anume, se va preciza în linia de comandă numele
acestuia, de exemplu: ant clean
o se pot specifica dependenţe între target-uri, folosind atributul depends: acesta
precizează target-urile care trebuie rulate înaintea target-ului curent. În exemplul dat,
rularea depinde de compilare. Un target este executat cel mult o dată, chiar dacă apare
în mai multe dependenţe.
o target-urile sunt constituite dintr-o serie de task-uri, de exemplu task-ul java în cadrul
target-ului run sau task-ul delete in cadrul target-ului clean
 elementul property permite definirea unei entităţi referite frecvent în cadrul fişierului, în
cazul nostru, numele unor directoare. Referirea unei proprietăţi se face prin secvenţa
${proprietate}
O facilitate importantă este posibilitatea de definire a căilor. Acest lucru este util, de exemplu, când
programul referă fişiere jar. Acestea trebuie introduse în classpath atât la compilare, cât şi la
rulare. În următorul exemplu, presupunem ca folosim fisierul lib.jar. Definim un element cale in
felul următor:

Acum, task-ul java poate fi scris în forma:

Observaţi referirea elementul path definit mai devreme, folosind atributul refid. Acum, classpath-ul
include atât fişierul jar, cât şi directorul build.

În cazul în care classpath-ul contine un singur element path, se poate înlocui elementul classpath cu
atributul classpathref.
De exemplu, secvenţa:

se poate restrânge mai întâi la:

sau chiar la:

Utilizatorii îşi pot defini propriile task-uri Ant, scriind câte o clasă pentru fiecare task, respectând o
anumită structură.
3. Sisteme de controlul versiunilor (Version Control Systems (VCS))

VCS-urile servesc la gestionarea versiunilor multiple ale fişierelor (în cayul nostrum, ale fişierelor sursă
ale unui proiect), într-un mediu colaborativ. Fiecărui document i se asociază un număr de versiune,
numit revision. La fiecare modificare, acesta este incrementat şi memorat împreună cu autorul
schimbării. La orice moment de timp se poate reveni (revert) la o versiune anterioară a documentului.
Un teren propice pentru întrebuinţarea unui astfel de sistem îl constituie wiki-urile.

Motivaţia principală constă în posibilitatea ca diferiţi membri ai echipei, aflaţi chiar în spatii geografice
diferite-îndepărtate, să poată lucra simultan la proiect, urmând ca, la final, modificările lor să fie reunite
în noi versiuni ale proiectului. Deasemenea, există şi alte avantaje. Când se observă un bug, se poate
reveni la o versiune anterioară, în vederea determinării momentului introducerii acestuia în
program/proiect. În acelaşi timp, se poate urma o dezvoltare pe ramuri (branches), în care se lucrează,
în paralel, la multiple versiuni ale proiectului - de exemplu, una în care se doreşte înlăturarea bug-urilor,
iar cealaltă, în care se urmăreşte dezvoltarea (adăugarea de noi functionalităţi, înaintea şlefuirii celor
existente.

O modalitate de reducere a spaţiului utilizat pentru stocarea intregului istoric al proiectului o constituie
delta compression, mecanism prin care se reţin doar diferenţele dintre versiunile successive. Se obţine
astfel o utilizare mai eficientă a spaţiului disponibil.

Exista două modele de VCS-uri:

 centralizat (ex: SVN): codul sursă este situat pe un server central, de unde clienţii pot obţine
variante de lucru pe masina locală (working copy). Dupa efectuarea locală a modificărilor,
dezvoltatorul solicită actualizarea variantei de pe server.
 distribuit (ex: Git): nu există un server central, procesul de sincronizare desfaşurându-se la nivel
peer-to-peer.

Terminologia folosită:
 repository: pe server, conţine ierarhia de fişiere şi informaţiile de versiune
 working copy: varianta locală, obtinută de la server, pe care se fac modificările
 checkout: aducerea pe maşina locală a versiunii de pe server, sub forma unei working copy
 update: actualizarea working copy-ului în funcţie de modificările survenite, între timp, pe server.
Se aduc doar fişierele modificate
 commit: cerere de publicare pe server a modificărilor făcute asupra working copy
 revision: versiunea unui document
 import: popularea iniţială a unui repository cu un proiect de pe maşina locală
 conflict: apare când 2 utilizatori vor să actualizeze acelaşi document, dar mecanismul nu este
capabil să îmbine cele 2 variante. În acest caz, se apelează la:
 resolve: acţiune pe care utilizatorul o execută pentru a înlătura un conflict (de exemplu, în cazul
de mai sus, acceptarea variantei celuilalt utilizator în defavoarea propriei variante)
  trunk: principala direcţie de dezvoltare a proiectului (ca înşiruire de revisions), în opoziţie cu:
 branches: ramuri secundare de evoluţie a proiectului (de exemplu, în care se testeaza feature-
uri noi)
 tag: instantaneu la un anumit moment de timp al proiectului, realizat pe trunk sau pe un branch.
E folosit de obicei pe cod stabil pentru a marca release-uri.
 merge(S1,S2): aplica la S2 dif(S1,S2)

3.1. Subversion (SVN)

SVN este un sistem centralizat, portabil, putând fi integrat cu numeroase IDE-uri ca, de exemplu,
Eclipse. Are urmatoarea arhitectură:
Pentru instalare, puteti rula, de exemplu, pe un sistem Debian (carte free, despre SVN):

De la client, accesul la repository-ul de pe server se poate face în trei moduri:

 printr-o schemă de adresare locală, când repository-ul şi clientul se află pe aceeaşi masină:
file://<cale_fisier>.
 prin protocolul SVN: svn://<host>/<cale_fisier>
 prin HTTP, folosind un modul al server-ului Apache.

O secvenţă obişnuită de lucru este următoarea:

1) Se creează unui repository pe server (cu specificarea căii):

2) Încărcăm sursele proiectului, pentru prima oară, în repository-ul creat.

  În comanda de mai sus, myproject reprezintă directorul care conţine sursele. Optiunea -m
asociază mesajul cu acţiunea. Ierarhia construită în repo are o structură specială, fişierele nefiind
vizibile ca atare.
3) Pentru afişarea conţinutului unui director din repository:

4) Obţinerea unei working copy pe maşina locală (în exemplu se aduce proiectul myproject din
repository în subdirectorul myproject, pe maşina locală):

5) Fişierele din working copy pot fi editate direct. În schimb, modificarea ierarhiei de fişiere (crearea
sau ştergere de fisiere/directoare) presupune utilizarea comenzilor de mai jos, nu a comenzilor
obişnuite, precum cp sau mv. Folosind comenzile obişnuite, SVN nu ar fi conştient de modificările
survenite):

6) Actualizarea working copy-ului, presupunând că repository-ul a fost modificat; se vor actualiza pe

server doar fişierele modificate, fără a aduce întreaga ierarhie, ca la checkout-ul iniţial.

7) Publicarea copiei locale pe server:

8) Vizualizarea modificărilor realizate local, de la ultimul update:

Subclipse
Subclipse este un plugin pentru Eclipse, ce permite interacţiunea în mod grafic cu repository-ul (vezi
tutorial).
Instalare
Verificati ca aveti instalată ultima versiune de Eclipse (4.2.1).
Astfel, din meniul Help alegeti Install new software, pentru a porni managerul de actualizari.
Introduceţi în campul Work with adresa: http://subclipse.tigris.org/update_1.6.x/.
Bifati a treia opţiune, „Subclipse“, apoi Next. Acceptaţi termenii de licenţiere şi apăsaţi din nou
Next. Apăsaţi, în final, Finish, pentru a începe descărcarea şi instalarea componentei Subclipse.
Obtinerea copiei de lucru
Deschideţi perspectiva SVN Repository Exploring şi selectaţi Add SVN Repository.
Specificaţi adresa maşinii de pe care obţineti, local, copia de lucru a proiectului SVN.

Ulterior, puteţi selecta folder-ele din proiect care vor fi aduse într-o copie locală. Alegeţi un folder şi
selectaţi Checkout. Puteţi specifica parametrii pentru această operaţie. Numele implicit de proiect va fi
acelaşi cu numele locatiei repository-ului ales. Puteţi, însă, specifica orice nume doriţi, după care
continuaţi, apasând Next:
Puteti preciza locaţia unde va fi salvata copia de lucru. Puteţi alege orice locaţie de pe disc, după care
apăsaţi Finish:
Acum puteţi vizualiza copia de lucru, în forma proiect Eclipse. În continuare, toate operaţiile SVN pot fi
declanşate prin apăsarea butonului drept al mouse-ului şi alegerea intrării Team.

3.2. GIT
Principala diferenţă dintre Git şi oricare alte sisteme de versionare (Subversion și prietenii săi inclusiv)
este modul în care Git își gestionează datele. Conceptual, majoritatea celorlalte sisteme își stochează
informaţiile ca o listă de schimbări asupra fişierelor. Aceste sisteme (CVS, Subversion, Perforce, Bazaar
și altele) văd informaţiile ca o mulțime de fișiere și schimbările asupra fișierelor în timp.

Git nu vede și nici nu stochează datele în acest mod. În schimb, Git consideră datele sale mai mult ca o
mulțime de instantanee ale unu mini sistem de fișiere. De fiecare dată când faceţi commit, sau salvaţi
starea proiectului dumneavoastră în Git, acesta practic salvează o poză a stării curente a tuturor
fișierelor din acel moment şi stochează o referință la acel instantaneu.
Pentru a fi eficient, dacă există fișiere care nu s-au schimbat, Git nu stochează fișierul iarăşi, ci doar o
legătură către fişierul anterior stocat identic cu cel din prezent.
Aceasta este o distincție importantă dintre Git și aproape toate celelalte VCS.

Git este un proiect free si open-source disponibil aici.

Caracteristicile acestui sistem sunt rapiditatea, design simplu, suport puternic pentru dezvoltare
nelineară (mii de branch-uri paralele), complet distribuit, abilitatea de a gestiona proiecte mari similare
cu kernelul Linux într-un mod eficient (din punct de vedere al vitezei și mărimii datelor).

Pentru a instala Git pe o masina Linux, rulati comanda:

Pentru a configura git local sau global puteti folosi utilitarul git-config.
Spre exemplu:

O altă variantă este sa editaţi fişierul ~/.gitconfig. Un exemplu de astfel de fişier de configurare
este ilustrat mai jos:
Un tool grafic util pentru Git, este gitk. Pentru a-l instala, rulaţi

Rezultatul afisat la rularea gitk în interiorul unui proiect Git este similar cu cel de mai jos:

Atunci când doriţi să lucraţi cu Git, veţi dori fie să obţineti o clonă locală a unui proiect remote, fie să
începeţi un nou proiect Git.
În primul caz, pentru a obţine o clonă locală a unui proiect remote, rulaţi:

În al doilea caz, vom crea un proiect Git local, pe care apoi să îl partajăm cu alţi utilizatori.
 Creăm proiectul:

 Iniţializam proiectul git în folderul creat:

 Realizăm modificările necesare:
o daca dorim să ignorăm anumite căi din cadrul proiectului (eg. .class, etc.), creăm un
fişier cu numele .gitignore în rădăcina proiectului şi adăugam pattern-uri de shell
care indică fişierele pe care git le va ignora la commit(eg.: bin/*.class)
 Verificăm statusul proiectului git folosind:

 Veţi putea observa fişierele adăugate pentru a fi comise, pe cele ne-adăugate precum şi pe cele
care nu au fost track-uite:
 Pentru a renunţa la modificările adăugate pentru commit, rulăm:

 Readucerea unui fişier modificat la versiunea remote/iniţială:

 Adăugarea fişierelor modificate:

 Verificarea log-ului proiectului:

 Commitem modificările făcute(cu semnatura utilizatorului curent):

 Verificarea log-ului proiectului pentru a ne asigura că noul commit apare acum în log:
 În cazul în care am uitat să ignorăm anumite fişiere, iar acestea au ajuns în ultimul commit,
rulăm:

 Pentru a modifica ultimul commit, putem folosi:

 Verificarea branch-ul current (în mod predefinit, branchul curent este master):

 Crearea unui nou branch din branchul curent:

 Ştergerea unui branch (care nu este branch-ul curent):

 Revenirea la un alt branch, sau commit_id:

 Pentru a comite remote:

  Pentru a descărca ultimele modificari remote, dar fără a le merge-ui cu repository-ul local:

 Pentru a lua ultimele modificări din repository-ul remote:

 Pentru a vedea diferenţele între versiuni de fişiere/branch-uri

Pentru mai multe comenzi utile pentru lucrul cu Git, vizitati tutorialul Git.

Egit
Este un plugin pentru Eclipse, care permite interacţiunea în mod grafic cu repository-ul.
Instalare
Verificati ca aveţi instalată ultima versiune de Eclipse (4.2.1).
Pentru instalare: din meniul Help alegeti Install new software, pentru a porni managerul de
actualizari.
Introduceti in campul Work with adresa: http://download.eclipse.org/egit/updates.
Bifati prima opţiune, „Eclipse Git Team Provider“, apoi Next. Acceptati termenii de licenţiere şi apăsaţi
din nou Next. Apasati, in final, Finish, pentru a incepe descărcarea şi instalarea componentei.
Exemplu
Creati un nou proiect Git. Adaugati in acest proiect o noua clasa Git“:
public class Git {
public static void main(String[] args) {
System.out.println("Git");
}
}
Pentru a creea un repository local: Click dreapta proiect → Team → Share Project → Git. Alegeti Create
Repository → Finish. În acest moment s-a creat un repository local. Repository-ul git se va stoca în
proiect, în folderul .git
EXERCIŢII - Ant, Eclipse, SVN, GIT
Utilizati scheletul de laborator.
1. Cercetati scheletul laboratorului si creati un nou proiect Java.
 Pentru crearea unui nou proiect: File → New → Create Project, dupa care aveti 3
optiuni:
o fie setati ca si locatie a noului proiect folderul obtinut in urma dezarhivarii
o fie importati continutul directorului
o fie copiati continutul directorului in directorul nou creat de Eclipse
 Directorul lib contine 2 subdirectoare:
o jars: contine 2 fisiere jar
o classes: contine 1 fisier class
 Rulati build.xml din interiorul Eclipse si observati outputul.
o fie folosind click dreapta pe fisier Run as→ Ant Build
o fie folosind meniul Run→External tools
2. Decomentati, pe rand, cele 3 linii din main si realizati modificarile necesare pentru ca programul
sa ruleze.
o Realizati, mai întâi, configurarile necesare direct in Eclipse (ignorand momentan fisierul
build.xml)
o Apoi, editati fisierul Ant:
 Definiti un element path, separat, ce va fi referit atat in target-ul de compilare,
cat si in cel de rulare.
 Atentie! Secventa <pathelement location=… /> poate fi folosita pentru
a indica:
 directoare ce contin fisiere .class sau
 fisiere jar individuale. Nu poate fi folosita pentru a include toate fisierele
jar dintr-un director.
 Incercati ambele variante:
 definiti cate un pathelement pentru fiecare jar in parte
 folositi fileset (manual Ant sau Google).
3. Utilizati scheletul de laborator.
Folosiţi SVN şi GIT pentru a crea un repository. Importaţi proiectul Eclipse (cel dat in scheletul de
laborator sau un alt proiect Eclipse) şi utilizaţi operaţiile descrise în acest material.

4. Dezvoltaţi aplicaţiile C++ SI Java pentru urmatoarele probleme:

a. Se citeste de la tastatura un numar intreg. Daca numarul introdus este prim sa se afiseze
un mesaj („Numarul ..... este prim!”), daca nu – sa se afiseze toti divizorii proprii ai
numarului.
b. Se introduce de la tastatura un numar natural, A, in baza 10. Sa se transforme nr. A din
baza 10 in baza n (n introdus tot de la tastatura).
c. Se introduce de la tastatura un numar natural, A, in baza n. Sa se transforme nr. A din baza n
in baza 10.
 d. Sa se verifice daca un numar natural, N, introdus de la tastatura, este palindrom (prima cifra
egala cu ultima, a doua cifra egala cu penultima, etc.)
e. Sa se calculeze si sa se afiseze cel mai mare divizor comun a doua numere (introduse de la
tastatura).
f. Sa se calculeze si sa se afiseze cel mai mic multiplu comun a doua numere (introduse de la
tastatura).
g. Sa se descompuna un nr. natural N (introdus de la tastatura) in produs de factori primi la
diferite puteri (ex: 20=2^2 * 5)
Arhivele corespunzătoare celor 2 proiecte vor fi numite NumePrenumeTema1C, respectiv
NumePrenumeTema1Java (exemplu PopaMirelaTema1C şi PopaMirelaTema1Java.

RESURSE
 JDK
 Eclipse
 Pagina oficiala Ant
 Manualul Ant
 Top 15 Ant Best Practices
 Pagina oficiala Subversion
 Version Control with Subversion, free book
 Subclipse
 Tutorial Subclipse
 Tutorial Git
 Tutorial EGit
 Arhitectura Git
 Setup Ubuntu SVN Server