vineri, martie 30, 2007

Releases in Maven

Procesul de release al proiectelor Java este total dependent de uneltele folosite. In cazul nostru de Maven. In primul rand trebuie sa clarificam cateva aspecte legate de Maven cum ar fi repository-uri si snapshot-uri. Apoi vom vorbi despre release-uri.

Repository-uri in Maven

Prin repository se intelege locul in care sunt depozitate/accesate artefactele, structurate pe grupe si versiuni (reprezinta de fapt un simplu director intr-un file system). Acestea sunt de mai multe feluri:


  • Local – este in structura de fisiere, implicit: USERHOME/.m2/repo; de aici sunt fosite in procesul de compilare (implicit compile) sau folosite in impachetare (runtime)
  • Remoute – un repository aflat in afara masinii locale - extern
    • intern – un repository in interiorul organizatie care poate fi deservit via http, ftp, file; prin intermediul acestui repository se partajeaza artefactele intre membrii echipei care lucreaza la proiect; a se intelege repository-ul unei companii
    • central – repository-ul central; in speta maven2.org

Deployment – procesul de stocare a artefactelor intr-un repository intern; artefactul poate fi astfel partajat de membrii echipei (echipelor) care dezvolta; se realizeaza prin mvn deloy.

Pentru deployere trebuie sa specificam locatia prin intermediul unei intrari distributionMnagement in POM-ul aplicatiei; deployerea se poate realize prin urmatoarele protocoale: file, SSH2, SFTP, FTP, SSH. Protocolul HTTP poate fi folosit doar pentru accesare.

A se face distinctie fata de deploymentul in serverul de aplicatii. Acest lucru se realizeaza prin accesarea unui task ant de copiere sau prin intermediul unui plugin de genul jboss-maven-plugin.

Instalare - install – procesul de stocare a artefactelor in repository-ul local; printr-o astfel de instalare artefactul devine dependenta accesibila celorlalte proiecte din local; se realizeaza prin mvn install.

SNAPSHOT-uri in Maven

Un aspect foarte interesant al utilizarii Maven este modul de lucru colaborativ la un proiect in interiorul unei organizatii avand mai multe module dezvoltate de developeri sau echipe diferite (un alt caz ar fi cel in care intreg proiectul la care lucreaza echipa are o dependenta de un alt proiect dezvoltat de o alta echipa).

Acest lucru presupune accesul rapid la artefactele produse de altii. O solutie simpla ar fi partajarea surselor via SCM (CVS sau SVN) de toate echipele si de toti dezvoltatorii. Acest lucru impune update de surse in local (impreuna cu POM-urile aferente) si build in local de catre fiecare developer, lucru care determina aceleasi artefacte generate pentru toti utilizatorii in repository-urile lor locale.

O alta solutie ar fi partajarea artefactelor via repository-ului intern al organizatiei. Acest lucru presupune deployment de artefacte. Aceasta este optiunea pe care Maven o prefera pentru lucrul colaborativ. Aici intervine notiunea de SNAPSHOT.

In Maven starea unui artefact in timpul dezvoltarii este cel de SNAPSHOT. Procesul de dezvoltare implica modificari frecvente ale surselor care dau artefactului o stare de instabilitate – cuprinde functionalitati care nu sunt clar specificate. Pentru a avea acces la ultima versiune a unui artefact inainte de a fi releasat, chiar cand el este in proces de dezvoltare, putem sa punem in POM-ul nostru o dependenta de tip SNAPSHOT. Un exemplu ar putea fi urmatorul:


<dependency>
<groupId>springframework</groupId>
<artifactId>spring</artifactId>
<version>1.2-SNAPSHOT</version>
</dependency>


Artefactele de tip SNAPSHOT sunt deployate intr-un repository intern pentru a fi usor accesibile celorlalti pe partcursul devoltarii (manual de unul din developeri sau autoamt de serverul de integrare continua). Prin procesul de deployere, artefactul de tip SNAPSHOT capata versiuni de genul 1.0-20070521.121124-1 (versiune majora.versine minora- timestamp-build). La fiecare noua deployere se schimba timestamp-ul si se incremeneteaza build-ul.

Pentru deployere se specifica un repository de SNAPSHOT-uri in POM (deployerea se va face prin protocolul file):


<distributionManagement>
<snapshotRepository>
<id>internal.snapshots</id>
<url>file://localhost/c:/repository/snapshots</url>
</snapshotRepository>
</distributionManagement>


Spre deosebire de release-uri, dependentele de tip SNAPSHOT ale proiectului sunt aduse in repository-ul local din repostory-ul intern de fiecare data cand se face build de proiect (chiar ultimul daca se prtecizeaza –U, altfel ultim in ordin de o zi). Se poate specifica explicit o politica de update de intr-un tag de forma updatePolicy. Un repozitory intern de artefacte de tip SNAPSHOT se precizeaza astfel in POM:

<repository>
<id>internal.snapshots</id>
<url>file://localhost/c:/repository/snapshots</url>
<snapshots>
<updatePolicy>interval:60</updatePolicy>
</snapshots>
</repository>


Pentru a evita deployment-ul manual de snapshot-uri se poate opta pentru a delega acest proces serverului de integrare (Continuum sau oricare altul). Acesta va deploya in favoarea noastra ultimele SNAPSHOT-uri de pe SCM intr-o locatie aleasa, in principiu in repository-ul intern de SNAPSHOT-uri.

Release-uri in Maven

Release-ul unui proiect in Maven se obtine prin intermediul unui plugin special numit maven-reelase-plugin. Acesta permite automatizarea procesului de release.


Daca nu e instalat in local trebuie instalat. O solutie check-out din repository-ul lui si mai apoi mvn install.

Pentru a crea un release trebuie indeplinite urmatoarele conditii :

  • proiectul trebuie sa aiba versiunea **-SNAPSHOT; si celelate submodule trebuie sa fie la fel
  • nu trebuie sa aiba dependente de alte artifacte sau plugin-uri care sunt **-SNAPSHOT; ca o solutie se va crea dependenta de versiunea care nu e SNAPSHOT (chiar daca nu este in POM)

Pasii necesari sunt urmatorii:

1. daca nu e implicit stabilit, se poate specifica locatia in SVN unde se va pune tag-ul creat:


org.apache.maven.plugins
maven-release-plugin

2. se apeleaza

# mvn release:prepare -DdryRun=truemvn
# release:cleanmvn release:prepare
  • prepare = pentru a pregati releas-ul - inseamna creare de tag in SVN, modificare de pom-uri
  • in cazul -DdryRun=true nici una dina ctivitatile prezentate nu vor fi comise efectiv (se creaza fisiere in care se reflecta modificarile)
  • in procesul de prepare se vor cere drept input versiunile - pentru tag si pentru viitoarea dezvoltare
  • cu release:clean se sterg aceste fisiere
  • cu release:prepare - se aplica schimbarile definitiv
  • in repository-ul local apar modificarile

3. se apeleaza

# mvn release:perform -DconnectionUrl=scm:svn:http://svn/repo/tags/1.1
# mvn release:perform
# mvn release:perform -DconnectionUrl=scm:svn:http://svn/repo/tags/1.1
-Dgoals="install"
  • pentru a face release la versiune - implicit deploy site-deploy
  • in mod usual se executa din director separat - ex prima linie (se va aduce de pe svn intr-un working directory unde se va face build, etc)