luni, decembrie 10, 2007

Spring Dynamic Modules for OSGi

OSGi ofera o facilitate foarte interesanta spre deosebire de serverele de aplicatii sau containerele usoare si anume injectarea de dependente in mod dinamic in runtime. Nici chiar Spring nu reuseste un astfel de lucru by default. In cazul Spring dependentele se injecteaza in runtime in mod static (o singura data si raman valabile pe tot parcursul existentei aplicatiei). In cazul severelor de aplicatiei resursele sunt luate explicit de pe JNDI. Spring beneficeaza de avantajele OSGi prin Spring Dynamic Modules for OSGi ajuns de curand la Release Candidate 1.

O lista de resurse pentru cei care vor sa invete Spring Dynamic Modules for OSGi:

  • De urmarit prezentarea de la 1.
  • De testat exemplele de la 2) in consola de Equinox (se poate descarca de aici sau se poate cauta printre plugin-uri din distributia voastra de Eclipse: org.eclipse.osgi.....). De asemenea o serie din exemplele de la 2) sunt prezentate folosind Plug-in Project wizard de la Eclipse (il puteti descarca de aici).
  • Documentatia de la 3) descrie modul in care Spring implementeaza OSGi. Un bun exemplu este sample-ul de pe site. Trebuie descarcata si testata.
  • La 4) se gaseste un blog cu o multime de resurse despre OSGi in geenral.
  • 5) este o relatare a unei prezentari a celor de la Spring Source (fostul Interface 21).
  • La 6) se poate vedea cum se poate scufunda Equinox intr-un server de aplicatii (pentru aplicatii web pluginabile).
  • La 7) snt o serie de interviuri care merita urmarite.

vineri, decembrie 07, 2007

Crearea unei librarii spre reutilizare aka expunerea unui API

Continut
  • un aspect important ar fi crearea de module distincte (Java jars, Osgi bundles) pentru partea publicata/publica (numita in continuare API) si partea de implementare/privata - Maven ca unealta de build incurajeaza o astfel de abordare (exemple:My Faces, si in general toate implementarile dupa API specifications - partea publica vine din specificatie; alte exemple SPI - interfete expuse spre implementare in JSE/JEE: driverele de JDBC, JNDI; connectorii JMS, JMX)
  • API-ul contine doar servicii - fara stare; DTO-uri - doar stare - pentru transport; exceptii - exceptii de business aruncate de API; enum-uri - colectii de constante (se va evita folosirea interfetelor pentru a defini constante)
  • impartirea librariei in mai multe module pe criterii tehnologice sau de business - utilizatorul poate sa creeze o dependenta numai de unele dintre ele - nu trebuie sa inghita tot (exemple de astfel de librarii: Compass, Spring)
  • dependentele intre pachete/module trebuie sa fie sub forma uneui DAG fara deepndente circulare - posibilitatea de a lucra in izolare pe pachete/librarii diferite releasate independent si cat mai des (evitarea share-ului in SCM a aplicatiei ca un intreg prin folosirea de proxy-uri de artifate - Artifactory)
  • cantainerele OSGi ofera un nivel avansat de incapsulare, permitand gestiunea dependentelor la o granularitate mai mica: la nivel de pachet
  • folosirea judicioasa a modificatorilor de acces (ex: field-uri private accesate prin mutators publici)
  • unitatea de relese este pachetul/modulul - pastrarea compatibilitatii inapoi intre versiunile majore (exemplu Spring)
  • un sistem clar de versionare a binarelor - regulile de la Apache sunt suficiente
  • reutilizare de cod reprezinta posibilitatea de a refolosi o librarie deja compilata (in compile time si runtime pentru client)

Integrare

  • distinctie intre partea publica si cea publicata (articol Martin Fowler)
  • dependente doar cu partea publicata dintr-o librarie straina utilizata in compile time si runtime (nici o dependenta de implemntare)
  • ascunderea sub key-uri a implementarilor (JNDI furnizat de serverul de aplicatii/registru de nume/Service Locator, IOC/fiseiere de configurare Spring/DI)
  • ascunderea implementarilor prin interfete din API-ul expus
  • injetarea de implementari in runtime (DI - implicit de catre container in boot time - Spring, Service Locator - explicit de catre client in runtime - EJB 3)
  • dependente injectate dinamic - serviciile OSGi - prin redepoyere si restartare de bundle-uri in containerul OSGi
  • partea publica va fi alcatuita dintr-un set de servicii expuse explicit prin care se da acces la businessul modelat de librarie - Services Facade Pattern
  • comunicarea se realizeaza prin Java Bean-uri DTO fara logica (functionalitate) - doar stare
  • clientul va folosi partea publicata a altei librarii doar printr-o zona de cod a sa Gateway Pattern fara a murdari restul
  • dependentele trebuie gestionate cu atentie (la nivel de module - Maven / la nivel de pachete si module OSGi)

duminică, decembrie 02, 2007

Eclipse shortcuts

Prezint o lista cu sortcut-uri folosite in mod curent in Eclipse. Cred ca IntelliJ Idea e totusi cel mai productiv IDE (unul in putinele produse care ar merita cumparate). As dori sa fac o palalela intre cele doua in masura timpului! Poate are cineva timp sa enumere shortcut-urile din IDEA?

  • setare shortcut-uri (WINDOW/PREFERENES/GENERAL/KEYS)
  • vizualizare shortcut-uri(CTRL+SHIFT+L)
  • auto complete (CTRL+SPACE)

  • formatare (CTRL+SHIFT+F)

  • inserare template (shortcut template + CTRL + SPACE si apoi se alege cu ENTER)
  • arata tooltip javadoc (F2 - initial trebuie atasate sursele)
  • supertype/subtype (CTRL+T - arata rapid ierarhia; F4 - arata ierarhia intr-un view separat)

  • cautare type (CTRL+T)

  • cautare resursa (CTRL+R)

  • pozitionare pe o linie (CTRL+L)
  • navigare intre editoare (CTRL+E; CTRL+F6)
  • sincronizare tree/sursa (butonul LINK WITH EDITOR)

  • expandare tree: (CTRL + numeric +) (CTRL + numeric *)

  • duplicare linie/selectie (CTRL+ALT+SAGEATA SUS/JOS)

  • stergere linie/selectie (CTRL+D)

  • mutare linie/selectie sus/jos (ALT+SAGEATA SUS/JOS)
  • comentare/adaugare comentariu javadoc (se scrie /** + ENTER)

  • comentare/decomentare linie/selectie (alternativ CTRL+/)

  • indentare (CTRL+I)
  • identare text stanga/dreapta linie/selectie (TAB/SHIFT+TAB)
  • selectare cuvant (CLICK DUBLU)
  • conversie litere mari/mici (CTRL+SHIFT+Y/X)
  • cautare/inlocuire in fisierul curent (CTRL+F)
  • cautare in fisierele din workspace (CTRL+H)
  • accesare surse - parte din proiect sau atasate explicit (CTRL + CLICK DREAPTA; F3; meniu contextual/ Open Declaration)
  • ierarhia de call-uri (meniu contextual/ Open Call History)

miercuri, noiembrie 07, 2007

Curs Java

Un curs introductiv de Java (fundamente + Web) prezentat timp de 2 zile celor de la Teamnet acum ceva mai mult de un an. Poate fi util pentru cei ce vor o introducere in limbaj si in tehnologii Web. Am uploadat PPT-urile folosite in prezentare. Am dat intamplator de ele pe HDD si am vrut sa testez cu ocazia asta slideshare.net. Chiar functioneaza bine (initial mi-a stricat putin PPT-urile la upload dar s-a rezolvat la urmatoarele incercari).





De asemenea proiectele demostrative continand exemple folosite in prezentari pot fi downlodate de aici (nu am mai sters binarele - clase si librarii). Sunt proiecte de IntelliJ IDEA (asa le-am facut atunci).

marți, noiembrie 06, 2007

UML Distilled

Zilele trecute am rasfoit din nou UML Distilled. Am surprins cateva idei pe care le prezint in continuare. Sunt legate mai putin de diagrame, mai mult de proces de dezvoltare si arhitecturi.

Pachete:
  • fisierele de configurare sparg dependintele statice de compilare intre pachete (aplicarea unui aspect, injectarea unei dependente)
  • dependentele induc modificari in mai multe locuri (defavorizeaza lucrul in izolare)
  • in Java principalul intrument de decompozitie este pachetul (a se vedea DOJO in JS, si pachetele de proceduri stocate si functii din Oracle)
  • dependentele intre pachete se preteaza a fi urmarite prin intermediul uneltelor (JDepend spre exemplu)
  • despre pattern-ul Facades (toate clasele dintr-un pachet sunt facute private si se creaza alte clase publice al caror rol este doar acele de a expune spre exterior servicii)

Metode de a obtine asincronism:
  • prin crearea unui nou thread - in mod normal threadul sursa si cel nou creat vor continua sa ruleze impreuna (vor lua coanta de microprocesor) (vor lua coanta de microprocesor)
  • comunicarea/trimiterea unui mesaj cu/unui thread (proces) care deja exista - cazul cozilor de mesaje care au asociati listeneri care pornesc in momentul generarii unui eveniment = primire de mesaj

Favorizarea compozitiei in defavoarea mostenirii:
  • in cazul unei mosteniri (la nivel de implementare sau specificatie) trebuie verificat ca generalizarea conceptuala se aplica altfel generalizarea nu este stabila la schimbari (adica a nu se folosi mostenirea pentru aspecte tehnologice: gen injectare de servicii de middleware)

Faza de elaborare:
  • aproximativ 1/2 din timp
  • poti porni planificarea dupa
  • riscuri (cerinte, tehnologii, skill-uri, politici)
  • se fac specificatii functionale (SRS)
  • se fac specificatiile tehnice (TSS)
  • se determina domain model (in paralel: model de date)
  • se face prototip vizual

vineri, octombrie 26, 2007

Our new car!

In final a venit Fordul (un Ford Focus in 4 usi). E mai frumos decat ne asteptam. A venit fix in 2 luni. Timpul promis de dealer.

Mai multe informatii daca doriti sa va luati un ford. Sunt doar trei dealeri in Bucuresti:

Mai multe informatii pe forum. Se pare ca service-ul e jalnic. O sa vedem prima oara cand o sa avem nevoie.

miercuri, octombrie 24, 2007

Software on Windows

Ce as dori sa am instalat pe o masina Windows pentru dezvoltare Java. Intradevar pe unele le-as dori pe o alta masina - cele care ar sta pe un server (eventual un Linux). Am pus [OS] acolo unde sunt free (e clar ca messenger-ele spre exempu nu au licenta open source!). Cele comerciale le-am adnotat cu [CO].

Am dat echivalent free pentru cele comerciale. Am sa incerc sa tin lista actualizata. Le gasiti si descarca cu siguranta de pe softpedia.com. Acolo le puteti compara cu altele din clasa lor.

duminică, octombrie 21, 2007

Arhitectura unui sistem

Nu putem sa vorbim despre lucruri atat de inalte fara a face referiri la inaintasi. Martin Fowler in articolul sau Who Needs an Architect, pune o intrebare interesanta Ce este un architect? Pentru aceasta trebuie sa raspunda la o alta Ce reprezinta arhitectura unei aplicatii? Si pentru aceasta este nevoit sa dea o definitie arhitecturii. Pentru asta face cateva incercari reusite:

“…the highest level concept of a system
in its environment. The architecture of a software
system (at a given point in time) is its organization
or structure of significant components
interacting through interfaces, those components
being composed of successively smaller components
and interfaces.”

“In most successful
software projects, the expert developers working
on that project have a shared understanding of the
system design. This shared understanding
is called ‘architecture.’ This understanding
includes how the system is divided into
components and how the components interact
through interfaces. These components
are usually composed of smaller
components, but the architecture only includes
the components and interfaces that
are understood by all the developers.”

“…architecture
is the set of design decisions that
must be made early in a project.”

De aici se desprinde ca arhitectura implica:

  • o viziune asupra componentelor constituiente ale unui sistem si a interactiunilor dintre ele
  • un consens intre membrii unei echipe
  • un set de decizii corecte care trebuie luate, sau mai bine zis ar fi de preferat sa fie luate

O greseala des intalnita este aceea de a considera ca rolul arhitecturii e acela de a crea sisteme optimizate. Adevaratul scop al arhitecturii este acela de a oferi o usoara mentenanta a sistemului, faza cea mai lunga a existentei unui proiect. Deci este o chestiune mai mult de organizare, o metoda de a gestiona complexitatea unui proiect prin sinteza, analiza si experienta.

Deci arhitectura = mentenanta.

Desigur aspectele legate de optimizare trebuie sa constituie o preocupare de baza chiar din fazele initiale ale proiectului. Dar din nefericire la un moment dat toate presupunerile devin simple supozitii, daca nu sunt confirmate de masuratori. Trebuie tinut cont ca business-ul modelat evolueaza si complexitatea creste. Deci, undeva in faza finala a unui proiect, cand business-ul implementat este stabil, trebuie sa existe o etapa de masuratori (facute cu un profiler si folosind unelte de stess, load testing, etc. ), care sa spuna in numere performantele, scalabilitatea, etc. unui sistem (link). Un set de citate care confirma cele spuse:

“More computing sins are committed
in the name of efficiency (without necessarily achieving it)
than for any other single reason - including blind stupidity.” - W.A. Wulf

“We should forget about small efficiencies,
say about 97% of the time:
premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%.”- Knuth, paraphrasing Hoare

“The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!):

Don't do it yet.” - Michael A. Jackson

Deci arhitectura!=optimizare.

In principiu putem gandi arhitectura unui proiect indiferent de tehnologiile folosite. Dar trebuie sa recunoastem ca acestea in sine aduc/impun elemente de arhitectura sistemului. Framework-urile alease, implementarile de specificatii, librariile folosite sunt hotaratoare. Cele mai importante sunt cele care impun un model de programare cum ar fi cazul framework-ului Spring sau a specificatiei J2EE. Ele trec peste aspecte specifice cum ar fi prezentarea web, persistenta, spre a oferi o intreaga infrastructura aplicatiei, asa cume cazul serverului de aplicatii in cazul J2EE si a containerului IOC in cazul Spring.

miercuri, octombrie 10, 2007

Timpi in dezvoltarea proiectelor

Timpii in dezvoltarea unui proiect reprezinta faze din procesul de dezvoltare. In esenta se refera la starea proiectului care evolueaza prin treceri intre surse - dezvoltare si artifacte - runtime. Din acet motiv se pot confuda cu fazele clasice din build-ul unui proiectului (in Maven spre exemplu – build phases, in cazul ANT nu existe faze standard).

Modul de lucru consta in repetarea urmatorilor pasi:

  1. se editeaza sursele, resursele, testele unitare
  2. se face build pentru a obtine artifactele
    • in procesul de build se executa si testele unitare, eventual se populeaza baza de date cu date de test (plugin Maven, DbUnit)
  3. artifactele se deployaza in serverul de aplicatii (la rece sau la cald)
    • se poate face manual, folosi plugin-uri de maven, target-uri de ant, sau manageri pe care ii pun la dispozitie serverele de aplicatii
  4. se testeaza functional
    • manual in browser
    • folosind teste automate (Canoo WebTests, Selenium IDE)

Timpii de dezvoltare pentru un proiect:

  • edit time
    • se referal la scrierea/editarea surselor si a testelor
    • in dezvoltare proiectul are o structura de directoare proprie
      • structura de directoare este sicronizata cu SCM-ul pentru a fi accesibila celorlalti dezvoltatori
      • in Maven exista o structura predefinita, in pom.xml se marcheaza doar exceptiile de la reguli
    • in urma procesului de build vor rezulta artifactele pentru runtime (aplicatii enterprise, web, simple jar-uri)
  • design time
    • se refera la folosirea unui IDE pentru a face design
    • in cazul componentelor Swing sau JSF
  • generation time
    • se refera la generarea de surse
    • se poate folosi un famework de tip MDA
    • se pot folosi diverse plugin-uri de maven sau tarsk-uri de ant de generare
  • compile time
    • reprezinta procesul de compilare
    • in CLASSPATH trebuie sa existe toate dependintile utilizate in surse
  • boot time
    • reprezinta faza de startare a unei masini virtuale cu incarcarea resurselor
    • se refera la un server de aplicatii, containere usoare, micro kernel-uri
    • in general serverul incarca foarte multe resurse la startare, gen pool-uri de obiecte, pool-uri de working threads care sunt ridicare in container si ready de a accepta request-uri pe mai multe fire de executie
    • se prefera un timp pierdut in bootare decat timp pierdut in runtime
  • configuration time
    • reprezinta o faza din procesul de boot in care sunt cititesc fisierele de configurare si se incarca resursele descrise acolo
    • spre exemplu: faces-config.xml pentru JSF, struts-config.xml pentru Struts, application-context.xml pentru Spring, etc
    • si alte fisiere de configurare conform anumitor specificatii: web.xml pentru aplicatia web, application.xml pentru aplicatii enterprise, fisiere in care se declara MBean-uri JMX, etc
  • run time
    • reprezinta faza de rulare a aplicatiei intr-o masina virtuala Java (JVM)
    • JVM permite expunerea de porturi prin care clientii (in general IDE-uri) se pot conecta pentru debug, profiling, configurare/management in runtime, etc
    • in general in JVM se porneste un server de aplicatii care incarca mai multe aplicatii definite de dezvoltator
    • la pornirea masinii virtuale se porneste un thread din grupul run care executa metoda main dintr-o clasa publica expusa ca parametru (poate fi chiar serverul de aplicatii daca aplicatia nu este stand-alone – acesta ridica in runtime aplicatiile deployate)

luni, octombrie 08, 2007

Compozitie fizica

Principalul aspect al arhitecturii il reprezinta decompozitia: impartirea intregului in parti constituente. Aceste parti pot fi fizice sau logice(conceptuale). Incercam sa le enumeram pe cele fizice si mai apoi pe cele logice specificand legaturile dintre ele.

Prin componente fizice se inteleg acele elemente de compozitie care au o reprezentare fizica (in general elemente induse de un limbaj de programare care au o reprezentare in file system). Enumerate de la complex la simplu ele sunt:
  1. Aplicatie enterprise (.ear)
  2. Modul (module .jar, .war, etc – unitate de deployment)
  3. Pachet (package – ierarhie de directoare in file system)
  4. Unitate de compilare (compilation unit - fisier)
  5. Tip (type)

In sine ele au relevanta si prezenta fizica in unul din timpii proiectului: compile, runtime, configuration time, etc.

Aplicatie enterprise
Un astfel de element de arhitectura apare numai in cazul unei aplicatii construite conform J2EE (serverul de aplicatii are container de EJB-uri) - altfel este indeajuns un modul web.
Impartirea pe aplicatii a sistemului se realizeaza pe criterii de business si de executie in runtime (serverul de aplicatii).
O aplicatie enterprise este alcatuita din mai multe module – jar, war, ejb, etc conform specificatiei J2EE – aceste module sunt descrise intr-un fisier de configureare conform J2EE.
Daca sunt mai multe aplicatii care alcatuiesc un singur sistem, acestea se integreaza prin puncte stabile de acces: expunere de API-uri (interfete, DTO-uri, exceptii) eventual URL-uri stabile (REST) si in cel mai nefavorabil caz prin baza de date (expunere de view-uri).
Securitatea este gestionata de serverul de aplicatii impreuna cu celelalte servicii de middleware si poate fi partajata intre toate aplicatiile sistemului printr-un sistem SSO.
Este de preferat ca plicatiile sa gestioneaza propria lor schema de baze de date (eventual un spatiu de nume dintr-o schema) si sa expuna API pentru integrare (expuneme de functionalitati spre exterior).
Pot expune interfete-serviciu pentru integrarea cu alte aplicatii din alte sisteme (cu care pot rula in acelasi JVM sau pe JVM-uri diferite).
Injectarea de implementari de servicii se face in runtime via JNDI (aplicatiile pot rula in acelas JVM sau JVM-uri diferite).


Modul
Reprezinta un element fizic reprezentat print-un .jar, .war, etc deploy-abil in runtime.
Un modul special este cel web (.war) care necesita un container de servleturi si JSP-uri pentru runtime si contine tipuri specifice: servlet, filtru si resurse specifice: JSP-uri, fisiere de configurare.
Impartirea pe module se realizeza in general pe criterii de deployment.
Un modul este alcatuit in edit time din mai multe pachete continand types (pot contine si resurse).
Modulele sunt generate din edit time de o unealta de build - Maven – pentru fiecare modul sursele si resursele sunt stocate in locatii diferite in file system.
In editare reprezita de asemenea subproiecte de Eclipse.
In general ele corespund in plan conceptual unui subsistem reprezintand intersectia intre un layer tehnologic si un vertical slice de business, dar pot contine un intreg layer sau un vertical slice.

Pachet
Reprezinta un element fizic al arhitecturii – o ierararhie de directoare in file system.
Un pachet cuprinde mai multe unitati de compilare care sunt la randul lor elemente fizice.
Conceptual este parte a unui subsistem. Mai multe pachete alcatuiesc un subsistem.
Impartirea pe pachete se realizeaza pe criterii de business si tehnologice.
In denumirea unui pachet se gaseste astfel cel putin numele unui subsistem + un nume specific din cele enumerate in continuare:
- managedbeans
reprezinta legatura intre layer-ul de prezentare si domeniu (corestund Action-urilor de Struts)
- services
sunt reprezentate de SLSB's
- domain
cuprinde entitatile necesare (si) in procesul de persistenta (EJB Entity Beans)
intre ele sunt relatii de asociere
nu au logica ci doar stare (domeniu anemic)
- dto
cuprinde obiecte folosite in transportul intre layerele alicatiei (numite si VO – Value Objects)
obiecte surogat, doar cu stare fara funtionalitate/logica
- exceptions
exceptii custom ale aplicatiei - de sistem sau de business

Unitate de compilare
O unitate de compilare cuprinde unul sau mai multe tipuri (unitatea de compilare = compilation unit este un fisier .java).
In Java orice unitate de compilare expune cel putin un tip public – trebuie sa aiba cel putin o definitie de tip पब्लिक.

Tip
Tipul = type reprezinta o definitie de clasa, interfata, enum, etc (prin type se intelege un tip de data referinta – variabile de tip referinta pointeaza in runtime spre o zona din memoria HEAP)
Un type este alcatuit din membri care pot fi
o metoda – logica/functionalitate
o field - stare
Un tip este incarcat de class loader in runtime.

vineri, septembrie 14, 2007

Carti cumparate in ultimul timp

In ultimul timp am reusit sa fac cateva achizitii interesante. Deja biblioteca tinde sa devina neincapatoare. Ce e adevarat e ca aceste carti tind sa devina prin diemnsiune adevarate caramizi.

Prima dintre ele este Fedora 7 and Red Hat Enterprise Linux Bible o carte completa despre Fedora Core si RHEL. Contine CD-urile cu sistemul de operare + extensii (desigur pot fi downladate de pe net). Cartea in sine este cuprinzatoare si foarte fumos scrisa.





A doua carte e Effective Java(TM) Programming Language Guide. O consider prima carte care trebuie citita dupa ce ti-ai asezat cat de cant fundamentul limbajului. Eu am luat-o in romana, intr-o traducere foarte buna. E aparuta in editura Teora acum cativa ani. E un miracol ca am gasit-o in librarii.



A treia carte e Design Patterns: Elements of Reusable Object-Oriented Software in limba engleza (adusa de la mama ei de acasa), carte fundamentala de design patterns care rezista ca valoare de ani de zile. Chiar daca codul exemplificat este C++, valabilitatea ei rezulta din faptul ca exprima concepte fundamentale de POO. Pentru Java eu recomand din O'reilly Head First Design Patterns (Head First).



vineri, august 03, 2007

Fedora Core 7

A fost o vreme cand prima oara pe calculator instalam Linux si apoi Windows (daca mai era nevoie). Era in anii studentiei si putin dupa, in dulcea periada petrecuta in Targu Iesilor. Facultatea se numea FCS, FII iar universitatea UAIC. Atunci era la moda Red Had 6. Se gasea peste tot, mai ales in revistele CIP drept CD supliment. Atunci internetul era o raritate - ne bateam pe locurile din laboratoare. Apoi internetul a fost pe toate drumurile. Acum e in toate casele.

In ultimul timp am simtit un trend favorabil in lumea Java pentru Linux. De cand Jboss a devenit parte a RedHat parca se intrevede o prietenie intre Java si Linux (unde Linux e preponderent orientat spre C, C++). In definitiv, Java a izbutit on the server side. Si Linux la fel. Java tinde sa devina cu adevarat OSS. Linux este deja. Java este o platforma pentru enterprise. Distributiile comerciale vor sa atinga (a se vedea RHEL) mediul enterprise.

Acum un an am cochetat putin cu Ubuntu. Anul acesta am vrut sa continui, dar nu mi-a placut. Mi-am adus aminte de vremurile cand RedHat era stapanul calculatorului meu, de cand foloseam RPM-uri. Cautand informatii despre RedHat am aflat ca nu mai este atat de OSS. Se pare ca undeva s-a petrecut un fenomen. RH s-a schimbat in RHEL (Enterprise Linux) ajuns la versiunea 5, iar partea free a fost rebranduit sub numele Fedora Core ajunsa la versiunea 7. Se pare ca RHEL isi trage seva din Fedora, care este mai des releasat si mai putin stabil in comparatie cu RHEL

De asemenea am simtit ca Linux-ul a evoluat fara ca eu sa iau parte la aceasta revolutie. Practic de 4-5 ani, nu am mai instalt nici o versiune de Linux pe calculatorul meu. In fapt Java inseamna independenta fata de masina fizica, sistem de operare, pentru ca rularea se petrece intr-o masina virtuala. Cu toate ca sistemul de fisiere, memoria, ... sunt ale SO-urilor. Iar JVM-ul e un simplu proces in OS. Deci vrand nevrand se leaga intre ele.



Din Fedora mi-a placut de data asta Gnome. Mai demult preferam KDE. Look-and-feel-ul este cu totul deosebit (Fedora are o tenta albastra, RHEL una rosie). Mi-a luat ceva timp sa-mi reamintesc comenzile. Timpul sterge foarte usor ceea ce nu e practicat continuu.

In general rulez in VMWare pentru ca din nefericire unele lucruri imi lipsesc sau nu le stiu inca. Am gasit un editor de CHM-uri dar Acrobat Reader pentru Linux nu-mi merge. Am instalat JDK, Maven, Eclipse, SQLDeveloper, JBoss Server fara nici un fel de problema.

sâmbătă, iunie 30, 2007

Cateva lucruri care m-ar interesa sa le fac dupa vacanta.

De curand am urmarit o prezentare interesanta referitoare la principiile arhitecturale folosite in Spring 2.0. Prezentarea lui Juergen Hoeller (Interface 21) mi-a dat un sentiment foarte placut la fel ca o mai veche prezentare a lui Joshua Bloch - How to design a good API . Ambele se refera la chestiuni foarte importante si fundamentale dar in general nespuse legate de arhitectura aplicatiilor (in principiu realizate in Java). In aceasta prezentare sunt cateva referinte la diverse unelete ce pot fi folosite in designul arhitectural al aplicatiilor. Dupa concediu sunt hotarat sa experimentez cateva.

Cel mai interesant mi se pare Sonarj al celor de la HELLO2MORROW. Documentatia aferenta este extrem de interesanta si enumera principii clare de arhitectura (in Java) - dependente slabe intre pachete, idea de vertical slices versus layers, etc. Din nefericire nu este free. O unealta free ar fi JDepend care permite in princupal detectarea dependentelor intre pachete. O alta unealta intereanta pare a fi Structure 101 - HEADWAY SOFTWARE - masaroara depedentele intre modulele aplicatiilor ( jar-uri). Interesante par a fi si Panopticode si MaintainJ. Toate aceste unelete au in general plugin-uri pentru Eclipse si Maven.

Alte unelte interesante ar fi: Glassbox o unealta de profiling in runtime bazata se pare pe MBeans (JMX). Difera astfel de alte unelte de profiling (JProfiler sau YourKit), prin faptul ca in cazul Glassbox se face mai mult o monitorizare a aplicatiei din punc de vedere al perfomantelor in timp ce ea este in pruductie, prin mesaje clare care anunta probleme de performanta.

sâmbătă, iunie 16, 2007

Content repository

Gestiunea continutului este o tema deschisa in Java. Fie ca este vorba de document management, Web content management , records management, in toate cazurile e vorba de gestiune de continut. Modul in care trebuie sa arate un astfel de API care sa permita abstractizarea lucrului la nivel de continut (repository-ul este o abstractizare peste file system si/sau baza de date) este standardizat mai nou in Java prin specificatia JSR 283 (mai e si vechea 170) - Java Content Repository. Implementarea de referinta pentru content repository este Jackrabbit.

Un interviu interesant despre content management in Java cules de pe DAILYMOTION.COM:


Prin CMS - Content Management System, intelegem un sistem care ne ajuta sa gestionam, culegem, manipulam continut (aceste implementari sunt construite peste API-urile descrise anterior si unele dintre ele sunt conforme cu specificatiile de la JCP). In cazul limbajului Java avem cateva implementari open source notorii (exista multe altele dar nu atat de importante)

  • Alfresco - document management, platforma matura, implementare cu librarii noi
  • Magnolia - Web content management, conforma cu Content Repository JSR
  • Daisy - Web content management, interesant
  • Nuxeo ECM - in plin proces de evolutie, rescriere din Pyton, inca instabil
Eu sunt impresionat de Alfresco - l-am testat si exista o carticica foarte buna care il descrie. Pentru document management Alfresco este un exemplu. Pentru gestiunea de continut Web, am testat Magnolia care mi-a lasat de asemenea o impresie placuta.

joi, mai 31, 2007

OpenID

OpenID pare a reprezenta o solutie universala de single sign on. Ce presupune acest lucru? Posibilitatea de a accesa diferite aplicatii Web printr-o singura autentificare. Specifice pentru Java cunosc trei astfel de sisteme: JOSSO (open source), JASIG (open source), CROWD (comercial Atlassian). Pe langa autentificarea unica, aceste trei framework-uri ofera posibilitatea de a gestiona toti userii diverselor aplicatii intr-un singur loc (Central Authentication Service). Sunt utile spre exemplu pentru mai mai multe aplicatii Web (care implementeaza diverse module de business) ruland sub o aceeasi fatada. Dar nu numai.

OpenID ofera mai mult decat framework-urile enuntate. El este un sistem universal de SSO asa cum se si autodefineste:
OpenID is an open, decentralized, free framework for user-centric digital identity.

luni, mai 28, 2007

Google Analytics

Google Analytics va ofera posibilitatea de a urmari accesarile sitului dumneavoastra de catre vizitatori.

Tot ce trebuie sa faceti este sa introduceti un mic fragment de java script in pagina dumneavoastra care va raporta accesarile.

Puteti identifica tarile din care sunteti accesati, ce pagini ale sitului sunt cele mai vizitate, numar de accesari, retelele din care sunteti accesati, numarul de revizitari, etc.

Pare a fi foarte util pentru un magazin virtual, pentru a determina drumul parcurs de clieenti in site. Datele pot fi salvate in diferite formate. Pare a fi o unealta utila pe langa altele oferite de cu atata generozitate de GOOGLE: Toolbar, Notebook, Blogger, Gmail, Picasa, Talk.

miercuri, mai 23, 2007

OSGi - the future

Prima oara am auzit de OSGi cand lucram cu Eclipse. Undeva intre versiunea 3.0 si 3.1 s-a produs migrarea din vechiul sistem de plugin-uri la o implemetare de OSGi, care a devenit cunoscuta sub numele de Equinox. A doaua oara cand am simtit ca e ceva bun cu OSGi a fost atunci cand Spring a ales sa ofere suport pentru OSGi in containerul lor (chiar a devenit un obiectiv important pentru Interface 21). In acest punct am inceput sa-mi pun intrebari. Ce reprezinta de fapt OSGi?

OSGi (Open Services Gateway initiative) este o specificatie intretinuta de OSGi Aliance ajunsa la versiunea 4. Scopul ei este acea de a defini The Dynamic Module System for Java ceea ce inseamna suport pentru module dinamice in Java, adica o inbunatatire a actual-ului sistem de module reprezentat prin clasicele jar-uri. Exista trei implementari open source ale acestei specificatii: Felix(Apache), Equinox(Eclipse), Knopflerfish(MakeWave). Exista si alte implementari comerciale. Referince implementation este Equinox care si-a dovedit calitatile si in
Eclipse. Exista alte incercari de a inbunatati vechile jar-uri, aflate sub umbrela jcp.org dar din nefericire par a fi doar incercari (JSR-227, JSR-291) fata de OSGi care cativa ani de existenta si destule impelementari.

Ce se intelege prin sistem dinamic de module in Java? Este tocmai ce jar-urile nu pot acum sa ofere: posibilitatea de a deploya in runtime in JVM, de a avea versiuni diferite ale aceluiasi modul in runtime, de a cupla modulele aplicatei printr-un numar cat mai mic si bine definit de puncte de interactiune, etc.

A deploya in runtime e posibul doar pentru aplicatiile enterprise (ear, war) prin mecanismele pe care le ofera serverul de aplicatii (JBoss se pricepe bine la asta - are un mecanism de incarcare de clase cu totul deosebit asa cum se vede aici) dar acest lucru nu este posibil cu un jar oarecare. Daca avem doua clase cu acelasi nume (provenite sa zicem din doua jar-uri diferit) doar prima clasa gasita in CLASSPATH va fi incarcata - nu se pune problema de versionare. Asa cum sunt cnstruite jar-urile, avand un jar in CLASSPATH-ul JVM-ului, toate resursele din acel jar pot fi incarcate de ClassLoader-eri - se creaza astfel dependente putenice intre modulele aplicatiei - inposibilitatea plugin-abilitatii.

Este interesant sa fii partas la inceputul unei tehnologii (mai bine zis la maturizarea ei - a inceput in 99). Deci mai bine zis sa fii contemporan cu ea. La fel cum AOP a devenit mijlocul standard de a oferi servicii de middleware, AJAX filosofia care ne-a scapat de refresh-ul pe pagina Web, OSGi va deveni modul standard de a realiza sisteme plugin-abile. Vom vedea.

marți, mai 22, 2007

Who is the boss, JBoss?

JBoss (acum divizie a Red Hat) trebuie urmarit cu atentie pentru ca se misca foarte repede si bine. Ce am retinut din istoria firmei este numele unui personaj ciudat - francez se pare - numit Marc Fleury (de curand a parasit firma imediat ce aceasta a fost preluata de Red Hat). E cel care a avut se pare ambitia de a construi un server de aplicatii open source spargand monopolul marilor corporatii IBM, BEA, Sun, Oracle lideri in acest domeniu. In fapt JCP-ul da specificatii pe care oricine poate sa le implementeze (daca are placerea si bunavointa).

E una din firmele care a promis si a facut soft Open Source Profesionist. A nu se intelege ca neaparat in open source nu sunt implicati bani. In spatele JBoss stau surprinzator fonduri de investitii care in mod normal investesc ca sa castige (se pare ca aceleasi investitori au inceput sa investeasca si in Interface 21 - cei care sunt in spatele framework-ului Spring - normal, tot pentru a castiga bani).

Ce e de remarcat la JBoss sunt oamenii. Fondatorul framework-ului Hibernate - Gavin King - s-a alaturat lor. Ce s-a intamplat de atunci? JBoss a lanseaza un server de aplicatii conform EJB3, o implementare de JPA avand la baza Hibernate. Mai mult, Gavin King pentru a incununa totul s-a apucat de facut Seam un framework care sa lege cele 2 tehnologii la moda (EJB3 si JSF) ducand adnotarile la extrem. Il pot compara cu Rod Johnson cel care a pornit Spring-ul. Si framework-urle lor sunt aproape la acelasi nivel: Seam creaza un ecosistem peste tehnologii standard gen EJB3 si JSF. Spring realizeaza un ecosistem fara cele 2 tehnologii enuntate. Dar cu un acelasi scop: usurinta in dezvoltare.

Dupa parerea mea in acest moment astea sunt si alternativele pe care trebuie mers. Ori EJB3 si JSF legate cu Seam ori Spring. Amandoua ofera acelasi unvers light de dezvoltare. JBoss, spre deosebire de Spring pare a costrui in jurul specificatiilor de la Sun de JEE 5.0. Spring construieste de la 0 pe JSE. Poate pentru ca JBoss au deja un server de aplicatii pe care il promoveaza (dar au si o versiune de EJB3 embedabila in Tomcat spre exemplu). Scopul declarat al Spring-ului a fost tocmai acela de a se feri de serverul de aplicatii (mai bine spus de containerul de EJB). Oricum e clar ca Spring-ul a fost cel care a produs tranformarea in iarna grea din EJB.

JBoss tinde sa fie o platforma de dezvoltare. Are in primul rand serverul de aplicatii, un container usor in genul lui Spring numit JBoss Microcontainer, are implementare de JMS (JBoss Messaging inlocuind neclusterabilul JBossMQ), un cache numit JBoss Cache, JBoss Rules - motor de reguli de bussines, jBPM - o implementare de BPM, multicasting cu JGroups, un container de portlets - JBoss Portal, etc. De curand a pus mana (nu se spune pre clar cum) pe produsele Exadel: un set de componente JSF numit RichFaces, Ajax4JSF - un framework care aduce Ajax in JSF fara Java Script, si IDE-ul de la Exadel (o implementare in Eclipse cu suport pentru JSF - nteresant suportul pentru facelets) care o sa fie lansat in curand (vara 2007) sub numele Red Hat Developer Studio si va ingloba toate toate unelte Eclipse ale JBoss-ului. Kito Mann explica mai multe.

Deci intr-un fel sau altul JBoss (padon... Red Hat) are in maini tot felul de bunatati pe care sunt sigur ca le va exploata cu succes. De ce i-au luat Red Hat? Pentru ca au nevoie de middleware pe Linux. Linux si Java par a deveni pieteni buni (se stie ca pana acum din cauza licentelor de la Sun, Linux-ul nu venea cu compilatorul si JRE-ul de la Sun). Lucrurile se schimba, Sun scotandu-si uneltele sub licente cu adevarat Open Source. Eu deja mi-am instalat UBUNTU (deocamdata in VMWare).

joi, mai 10, 2007

E un sentiment placut sa fii alaturi de cei MARI.

Viitorul limbajului Java depinde de Sun dar se amensteca cu viitorul unor monstri precum Oracle, IBM (cateodata imi pare rau cand ma gandesc ca Microsoft evolueaza intr-un univers paralel – oare unde ar fi fost Java daca …). Unul din sefii Oracle prezinta viziunea acestei companii, viziune in care Java joaca un rol foarte important. Il puteti urmari aici.

In continuare prezint un sumar al celor spuse iar la final sumarul prezentat chiar de vorbitor (in engleza).

Perspectivele pentru Oracle in partea de programare par a fi urmatoarele:

  1. Suport in partea de middleware pentru EJB3 (session beans si messages driven beans) si pentru noul API standard pentru persistenta numit JPA (entity beans din EJB3).
  2. Via EJB3 se ofera suport pentru cele doua paradigme:
    • request/reply – service oriented design pattern style – SOA (expunere de servicii - session bens, webservices)
    • publish/subscribe - event driven style – EDA (cozi de mesaje – implementari de JMS, eventual message driven beans drept listeneri)
  3. Suport in partea de prezentare pentru JSF. Suport pentru AJAX si DHTML integrat in JSF plus randare spre clienti mobili. Intr-un cuvant clienti bogati si/sau mobili (in JSF ambele aspecte sunt rezolvate prin constructia framework-ului)
  4. Suport pentru orchestrare de servicii via BPEL pentru interactiunea intre serviciile oferite de diverse sisteme. S-a enuntat si support pentru sisteme de workflow care implica interactiunea umana – probabil se refera la BPM.
  5. Suport pentru containere usoare – in special Spring (Interface 21) si mai ales pentru modularizarea sistemelor via OSGI. Spring ofera deja integrare cu diverse implementari ale OSGI.
  6. Au achizitionat Tangosol Coherence cei care detineau un renumit system de cache distribuit (commercial din pacate). Si-au asigurat partea de caching distribuit pentru clustere peste servere de aplicatii (in rack-urile de servere de baze de date probabil deja sunt stapani).

So, in summary, from a programming model point of view, we believe there are three important trends. The combination of AJAX, JavaServer Faces and Web Tool to provide a much richer model for users to access applications and work with each other. Second, the programming model with the emergence of lightweight containers, OSGi and the Java Persistence API providing a much simpler model to build business logic and deploy them on lightweight containers or modular containers. Third, the combination of grid computing technology for both compute grids as well as data grids and our acquisition of Tangosol provides us an operational fabric to support very, very high scalability and transactional applications using that are built to this programming model.

Thomas Kurian is Senior Vice President of Development for Oracle middleware platform products, including Oracle Application Server and development tools.

joi, aprilie 19, 2007

IN MY POCKET

Pe la inceputul anului am facut marele pas. Am achizitionat un pocket HP IPAQ MOBILE MESSENGER. Ce e foarte interesant legat de el este faptul ca e chiar util. Are GPS, GSM/GPRS/EDGE, Wireless, Bluetooth, IrDA, camera foto. Intr-un cuvant tot ce poti sa vrei de la un astfel de dispozitiv.

Pe el ruleaza Microsoft Windows Mobile 5.0 for Pocket PC, Phone Edition. Are o masina virtuala Java - ESMERTEC - preinstalata gata sa ruleze orice fel de midlet. De asemea preinstalt navigatorul TOM TOM cu posiilitatea de a descarca gratuit o harta. Chiar am folosit harta Romei dar nu consider Tom Tom fiind prea placut. Eu prefer iGO. Am testat si Route 66 dar nu imi place chiar deloc.

Vechea cartela de pe telefonul mobil (ORANGE) a fost indeajuns sa o introduc la locul ei si telefonul a si pornit recunoscandu-mi numerele. Pentru a activa GPRS a trebuit sa vorbesc cu cei de la Orange. Se plateste doar per trafic efectuat. La inceput se conecta anapoda si am platit inutil. Apoi am activat un contor si totul a devenit mai clar.

Incerc sa enumer in continuare o serie de soft-uri care se dovedesc utile in viata de zi cu zi.

iGo My Way - cel mai bun soft de navigare
eWallet - gestiuena numerelor si parolelor de cart si altor informatii utile
pRssReader - un reader de RSS foarte util (gratuit)
PocketMusic - un mp3 player gen WinAMP
Skype - clientul de Skype pentru pocket (gratuit)
Spb GPRS Monitor - un monitor al traficului GPRS
Spb Menu - un meniu care customizeaza
WorldMate - un porgramel pentru calatorii - vremea, curse aeriene, conversii de valute
Yahoo! Go - pentru sincronizarea mail-urilor de pe Yahoo
Pocket Mechanic - pentru intretinerea pocketului

Toate aceste produse le puteti urmari si pe unele descarca de pe PocketGear.com.

SPB SOFWARE HOUSE este o firma foarte interesanta care face tot felul de produse pentru pocket. E o curiozitate cum poate sa faca produse atat de utile si de frumoase.

Ce e intradevar util sunt feed-urile RSS. Un alt aspect interesant este starea vremii. Apoi email-urile. Toate acestea presupun un proces de sincronizare pe care il fac de obicei cand sunt sub wireless sau ActiveSync (mai rar sub GPRS).

miercuri, aprilie 18, 2007

Java Developer

Desigur postul anterior este o gluma de 1 aprilie. Cred cu hotarare in Java si in viitorul limbajului. Daca e ceva frumos in Ruby(on Rails) trebuie importat in Java.

Punctul meu actual de interes este JSF. Am testat mai toate implementarile open source si pot spune ca in sfarsit arata bine. Am observat ca mai toate cartile de JSF sunt scrise in 2004 (am o singura carte din 2006). E un semn ca tehnologia e deja fixata. Impelemntarile opensource pe care le stiu sunt urmatoarele:IceFaces, Woodstock, Rich Faces, ADF, Tomahawk.

Un alt subiect interesant il reprexinta EJB 3, mai ales noua specificatie pentru persistenta JPA. Am testat implementarea de la JBoss peste Hibernate. Implementarile existente sunt doar doua (una peste Hibernate si cealalta peste TopLink) JBoss Hibernate EntityManager, GlassFish TopLink Essentials.

In build m-am luptat in ultimul timp cu Apache Maven.

In rest televizorul si radioul meu au ajuns sa fie computerul (2 ani de cand le-am exclus din viata mea). Cateva locatii interesante in care puteti gasi prezentari video referitoare la Java si tehnologii aferente: Java Developer's Journal, The Server Side, InfoQ, Parleys. Prezentari audio puteti gasi pe The Java Posse, Feather Cast.

duminică, aprilie 01, 2007

Stop to Java

In sfartit m-am decis. Java nu mai merita deloc interesul meu. Dupa 5 ani de Java, am ales in sfarsit un alt limbaj de programare.

In week-end am incercat Ruby si sunt foarte incantat de tot ce ofera. Am testat si Ruby on Rails si mi-e foarte clar ca toate framework-urile Web din Java sunt deprecated. Incarcati ruby in consola. Nu e asa ca e interesant?

Sunt foarte multe aplicatii facute in Ruby on Rails pe care le-am incercat si chiar folosit: Basecamp, Campfire, Fluxiom. Pot sa spun ca Ruby on Rail aduce deja un standard pentru Web. Nume sonore au ales Ruby, spre exemplu Martin Fowler. Si comunitatea care sta in jurul limbajului e plina de entuziasm - sunt multe librarii in repository-ul de pe net. Si foarte, foarte, foarte multe carti.

Toate tool-urile tind sa aiba un echivalent in Rooby. Spre exemplu Cruise Control are acum Cruise Control RB.

Daca firma voastra a ales deja Ruby si aveti nevoie de un om dornic sa invete repede si sa devina expert in domeniu puteti sa ma cautati.

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)