Învăţăm Împreună

Introducere în Apache Maven 2, Partea 5 - Plugin-urile şi goal-urile Maven

2009-05-30T20:47:00.001+03:00

Nucleul Maven este foarte puţin implicat în sarcinile legate de build-ul proiectului dvs. Singur, Maven nu ştie cum să compileze codul dvs. sau cum să creeze un fişier JAR. Maven deleagă tot acest lucru către plugin-urile Maven, cum ar fi plugin-ul Compiler pentru compilare, plugin-ul Jar pentru crearea fişierelor Jar, etc. Aceste plugin-uri sînt descărcate din repozitoriul central Maven la prima necesitate. Atunci cînd descărcaţi Maven, dvs. descărcaţi doar nucleul Maven, care constă dintr-un shell care ştie doar să analizeze comenzile din linia de comandă, să gestioneze classpath-ul, să analizeze fişierul POM şi să descarce plugin-uri Maven atunci cînd este necesar. Prin păstrarea plugin-ului Compiler separat de nucleul Maven şi asigurarea unui mecanism de actualizare, Maven face mai uşor pentru utilizatori de a avea acces la cele mai noi opţiuni în compilator. În Maven, noi nu definim sarcina de compilare într-un fişier de build, în schimb folosim plugin-ul Compiler care este împărtăşit de fiecare utilizator de Maven. Dacă apare o îmbunătăţire a plugin-ului Compiler, atunci fiecare proiect care utilizează Maven imediat poate beneficia de această îmbunătăţire fără a fi nevoie de careva schimbări.

Un Plugin Maven este o colecţie de unul sau mai multe goal-uri (scop, sarcină). Un goal este o sarcină specifică, care poate fi executat ca un goal de sine stătător sau împreună cu alte goal-uri ca parte a unui build mai mare. Un goal este o unitate de lucru în Maven. Exemple de goal-uri includ goal-ul compile din plugin-ul Compiler care compilează tot codul sursă al proiectului, sau goal-ul test din plugin-ul Surefire care execută unit testele. Goal-urile sînt configurate cu ajutorul proprietăţilor de configurare care pot fi utilizate pentru a personaliza comportamentul acestora. [Click mai jos pentru a citi articolul în întregime]

Maven prevede de asemenea posibilitatea de a defini plugin-uri personalizate. Un plug-in personalizat poate fi scris în Java sau în orice alt limbaj, inclusiv Ant, Groovy, Ruby, beanshell. Cînd scrieţi un plug-in propriu, dvs. pur şi simplu grupaţi un set de goal-uri într-un singur artifact de plugin. Fiecare goal în Maven corespunde unui MOJO (Maven Old Java Object). De exemplu goal-ul compiler:compile corespunde clasei CompilerMojo în Plugin-ul Maven Compiler şi goal-ul jar:jar corespunde clasei JarMojo în Plugin-ul Maven Jar.

Pentru a executa un singur goal al unui plug-in Maven vom folosi sintaxa mvn compiler:compile, unde compiler este prefixul plugin-ului şi compile este goal-ul. De asemenea putem transmite perechi -Dname=value ca argumente atunci cînd executăm un goal. Aceste argumente sînt sub forma de -D proprietăţi, similare cu acele opţiuni care pot fi transmise către Java Virtual Machine din linia de comandă.

Acum, să descriem mai detaliat ce înseamnă prefixul unui plugin. Deoarece fiecare plugin Maven este un artifact Maven, el ar trebui să fie referit folosind coordonatele Maven. Specificarea de fiecare dată a groupId, artifactId, version şi goal-ulului în linia de comandă este greoaie. Pentru a rezolva acest lucru, Maven atribuie cîte un prefix fiecărui plugin. Acum în loc să tastaţi:

mvn org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile

puteţi folosi prefix-ul de plugin compiler şi transforma linia de comandă de mai sus în mvn compiler:compile. Cum Maven transformă compiler:compile în org.apache.maven.plugins:maven-compiler-plugin:2.0.2? Maven se uită într-un fişier în repozitoriul Maven pentru a obţine lista de plugin-uri pentru un anumit groupId. În mod implicit, Maven este configurat să caute plugin-uri în două grupe: org.apache.maven.plugins şi org.codehaus.mojo. Cînd Maven caută plugin-uri pentru un anumit groupId, el preia un fişier XML din repozitoriul Maven care conţine metadate despre artifact-ele conţinute într-un grup. Acest fişier XML este specific pentru fiecare repozitoriu. Dvs. puteţi vedea metadatele Maven pentru grupul org.apache.maven.plugins în repozitoriul local Maven (<user_home>/.m2/repository) în fişierul org/apache/maven/plugins/maven-metadata-central.xml. Mai jos este arătat un fragment din fişierul maven-metadata-central.xml din grupul org.apache.maven.plugins.

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <plugins>
    ...
    <plugin>
      <name>Maven Clean Plugin</name>
      <prefix>clean</prefix>
      <artifactId>maven-clean-plugin</artifactId>
    </plugin>
    <plugin>
      <name>Maven Compiler Plugin</name>
      <prefix>compiler</prefix>
      <artifactId>maven-compiler-plugin</artifactId>
    </plugin>
    <plugin>
      <name>Maven Jar Plugin</name>
      <prefix>jar</prefix>
      <artifactId>maven-jar-plugin</artifactId>
    </plugin>
    ...
  </plugins>
</metadata>

După cum se poate vedea anume fişierul maven-metadata-central.xml în repozitoriul local este ceea ce face posibil ca dvs. să executaţi plugin-uri folosind doar prefixul plugin-ului.

Plugin-ul de Ajutor Maven

Plugin-ul de Ajutor Maven vă permite să aflaţi listă de atribute a unui plugin Maven, să afişaţi POM-ul efectiv, să vedeţi setările efective sau lista activă de profiluri Maven.

Plugin-ul de Ajutor Maven are patru goal-uri. Următoarele comenzi oferă cîteva informaţii generale despre cele patru goal-uri:

help:describe - descrie atributele unui plugin. Acest goal vă arată informaţii despre un plugin sau un goal al unul plugin. Cu ajutorul parametrului plugin puteţi specifica plugin-ul pe care doriţi să-l investigaţi. Ca valoare a acestui parametru poate fi atît prefixul plugin-ului (de exemplu compiler pentru maven-compiler-plugin) sau groupId:artifactId[:version] unde versiunea este opţională. De exemplu, următoarea comandă foloseşte goal-ul describe al plugin-ului de Ajutor pentru a afişa informaţii despre plugin-ul Maven Compiler:
mvn help:describe -Dplugin=compiler
...
[INFO] [help:describe]
[INFO] org.apache.maven.plugins:maven-compiler-plugin:2.0.2

Name: Maven Compiler Plugin
Description: Maven Plugins
Group Id: org.apache.maven.plugins
Artifact Id: maven-compiler-plugin
Version: 2.0.2
Goal Prefix: compiler

This plugin has 2 goals:

compiler:compile
Description: Compiles application sources
Deprecated. No reason given

compiler:testCompile
Description: Compiles application test sources
Deprecated. No reason given

For more information, run 'mvn help:describe [...] -Ddetail'
Puteţi obţine acelaşi lucru utilizînd sintaxa groupId:artifactId[:version]
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin
Dacă doriţi ca Plugin-ul de Ajutor să afişeze lista completă a goal-urilor cu parametri, executaţi goal-ul help:describe cu parametrul detail, după cum urmează:
mvn help:describe -Dplugin=compiler –Ddetail
Pentru a obţine informaţii despre un singur goal, setaţi parametrul mojo alături de parametrul plugin. Următoarea comandă afişează toată informaţia cu privire la goal-ul compile din plugin-ul Compiler:
mvn help:describe -Dplugin=compiler -Dmojo=compile -Ddetail

Celelalte trei goal-uri: active-profiles, effective-pom şi effective-settings trebuie să fie rulate în directorul de bază ale unui proiect.
help:active-profiles - afişează profilurile (proiect, utilizator, la nivel global) care sînt active pentru build.
help:effective-pom - afişează POM-ul efectiv pentru build-ul curent luînd în consideraţie profilurile active.
help:effective-settings - afişează setările calculate pentru acest proiect avînd în vedere orice profil de îmbunătăţire şi de moştenirea setărilor globale.

Aici încheiem acest post. În următorul post vom vorbi despre Ciclul de viaţă Maven.

Introducere în Apache Maven 2, Partea 4 - Dependenţele proiectelor

2009-05-24T11:20:00.001+03:00

Posibilitatea de a localiza uşor un artifact într-un repozitoriu pe baza coordonatelor Maven, ne oferă posibilitatea de a defini dependenţe către alte artifacte în POM-ul proiectului. Dacă veţi analiza POM-ul care a fost arătat în articolul precedent Introducere în Apache Maven 2, Partea 3 - Project Object Model (POM), în paragraful Coordonatele Maven, veţi vedea că există o secţiune care se ocupă de dependenţe, şi că în această secţiune se conţine o singură dependenţă către JUnit.

Maven poate gestiona atât dependenţe interne, cît şi externe. O dependenţă externă pentru un proiect Java ar putea fi o bibliotecă, cum ar fi Log4J sau Spring Framework. O dependenţă internă este reprezentată prin unul din proiectele dvs. care depinde de un alt proiect al dvs. De exemplu, un proiect cu o aplicaţie web, care depinde de un alt proiect care conţine service clasele sau logica de persistenţă.

Pentru a înţelege mai bine, mai jos sînt arătate câteva exemple de dependenţe:

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>org.apache.velocity</groupId>
      <artifactId>velocity</artifactId>
      <version>1.6.2</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
      <version>2.4</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
  ...
</project>

[Click mai jos pentru a citi articolul în întregime]

Prima întrebare pe care o să vă o puneţi este: De unde am ştiut noi exact care sînt valorile pentru groupId şi artifactId pentru aceste artifacte? Puteţi localiza toate artifactele Maven folosind pagina web http://www.mvnrepository.com. Acest site oferă o interfaţă de căutare pentru repozitoriul Maven. Cu ajutorul lui puteţi căuta artifactele de care aveţi nevoie pentru a le adăuga ca dependenţe în proiectul dvs. Aveţi posibilitatea să căutaţi un artifact după groupId, artifactId sau chiar descriere. La căutare, o să vă fie afişat artifactul cu lista tuturor versiunilor cunoscute de repozitoriul central Maven. Făcînd click pe detaliile pentru o anumită versiune, veţi fi redirecţionat către o altă pagină care va conţine elementul <dependency> pe care îl puteţi copia şi insera în propriul pom.xml. Unele dintre aceste dependenţe sînt atât de des utilizate (de exemplu JUnit), încît le veţi memoriza foarte rapid groupId şi artifactId.

După cum se vede din fragmentul de POM de mai sus, o dependenţă se declară folosind groupId, artifactId şi version ale artifactului, şi scope (domeniul de aplicare) al acestei dependenţe.

Maven prevede diferite domenii de aplicare(scope) ale dependenţelor. Domeniul de aplicare dirijează care dependenţe sînt disponibile, şi în care classpath. Totodată el dirijează care dependenţe sînt incluse în distribuţie o dată cu aplicaţia. Să examinăm fiecare domeniu de aplicare în detaliu:

compile - este domeniul de aplicare implicit. Toate dependenţele au domeniul de aplicare compile în cazul în care domeniul de aplicare nu este specificat. Dependenţele cu domeniul de aplicare compile sînt disponibile în toate classpath-urile, de asemenea ele sînt ambalate(packaged) odată cu aplicaţia la distribuire.
provided - sînt folosite atunci când aşteptaţi ca JDK, container-ul sau server-ul să vă ofere aceste dependenţe. De exemplu, dacă dezvoltaţi o aplicaţie web, veţi avea nevoie de Servlet API disponibil în classpath-ul de compilare pentru a compila un servlet, dar nu doriţi să includeţi Servlet API la ambalare în WAR, deoarece jar-ul cu Servlet API este furnizat de server-ul sau servlet container-ul dvs. Dependenţele provided sînt disponibile doar în classpath-ul de compilare, nu runtime. De asemenea ele nu sînt ambalate odată cu aplicaţia la distribuire.
runtime - sînt necesare pentru executarea şi testare sistemului, dar nu sînt necesare pentru compilare. De exemplu, aţi putea avea nevoie de jar-ul cu JDBC API la momentul compilării şi de implementarea driver-ului JDBC numai la runtime.
test - nu sînt necesare în timpul funcţionării normale a aplicaţiei şi sînt disponibile numai în perioada de compilare şi execuţie a testelor.
system - este similar cu provided cu excepţia faptului că va trebui să oferiţi o cale explicită către fişierul jar în sistemul de fişiere local. Acest lucru este destinat pentru a permite compilarea cu folosirea bibliotecilor native. Dacă declaraţi domeniului de aplicare system, atunci trebuie să specificaţi de asemenea şi elementul systemPath.

Pe lîngă specificarea unei versiuni fixe, puteţi de asemenea specifica o serie de versiuni care ar putea satisface o anumită dependenţă. Puteţi face acest lucru prin plasarea unui sau mai multor numere de versiuni între următoarele caractere:

(, ) - Cuantificatori exclusivi

[, ] - Cuantificatori inclusivi

De exemplu, dacă doriţi să accesaţi orice versiune JUnit mai mare sau egală decît 3.8, dar mai mică decît 4.0, dependenţa dumneavoastră ar arăta aşa cum este arătat mai jos:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>[3.8,4.0)</version>
  <scope>test</scope>
</dependency>

Dacă doriţi să depindeţi de orice versiune de JUnit nu mai mare decît 3.8.1, atunci trebuie să specificaţi doar o limită superioară inclusiv. Versiunea înainte de, sau după virgulă nu este necesară, şi înseamnă +/- infinit.

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>[,3.8.1]</version>
  <scope>test</scope>
</dependency>

Notă: Versiunea [1.2] înseamnă doar versiunea 1.2 şi nimic altceva. Când se declară o versiune normală, cum ar fi versiunea 3.8.1 de Junit, intern, aceasta este reprezentată ca: "permite orice, dar prefera 3.8.1". Acest lucru înseamnă că atunci când este detectat un conflict, Maven este autorizat să folosească algoritmi de conflict pentru a alege cea mai buna versiune. Dacă se specifică [3.8.1], aceasta înseamnă că doar 3.8.1 va fi folosit şi nimic altceva. Dacă în altă parte există o dependenţă care a specificat [3.8.2], atunci veţi obţine o eroare de conflict la build.

Dependenţe Tranzitive

O dependenţă tranzitivă este o dependenţă de către o altă dependenţă. Dacă un proiect A depinde de un alt proiect B, care la rîndul său depinde de proiectul C, atunci proiectul C este considerat o dependenţă tranzitivă a proiectului A. Dacă proiectul C depinde la rîndul său de proiectul D, atunci şi proiectul D de asemenea este considerat o dependenţă tranzitivă a proiectului A.

Maven poate gestiona dependenţele tranzitive şi scuti developer-ul de necesitatea de a găsi toate dependenţele necesare pentru a compila şi rula o aplicaţie. Puteţi doar să declaraţi o dependenţă de vre-un framework sau bibliotecă fără să vă faceţi griji pentru depistarea tuturor dependenţelor pe care acestea le au.

Maven realizează acest lucru prin construirea unui graf de dependenţe şi rezolvarea tuturor conflictelor şi suprapunerilor care ar putea apărea. De exemplu, dacă Maven găseşte două proiecte care depind de aceleaşi groupId şi artifactId, acesta va selecta în mod automat care dependenţă să o folosească, întotdeauna favorizînd cea mai recentă versiune a dependenţei. Deşi sună convenabil, există unele cazuri în care dependenţele tranzitive pot cauza unele probleme de configurare. În astfel de scenarii, puteţi utiliza excluderea de dependenţe.

Mai jos este arătat un exemplu în care se adaugă o dependenţă de proiectul A, dar se exclude dependenţa tranzitivă de proiectul B şi se înlocuieşte cu o dependenţă de proiectul X:

<dependencies>
  <dependency>
    <groupId>com.company.project</groupId>
    <artifactId>project-a</artifactId>
    <version>1.0</version>
    <exclusions>
      <exclusion>
        <groupId>com.company.project</groupId>
        <artifactId>project-b</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
  <dependency>
    <groupId>com.company.project</groupId>
    <artifactId>project-x</artifactId>
    <version>1.0</version>
  </dependency>
</dependencies>

După cum puteţi observa nu există nici un semn că dependenţa de proiectul X este o înlocuire. În cazul acesta proiectul X este o bibliotecă care asigură acelaşi API ca şi proiectul B. Pentru a înlocui o dependenţă tranzitivă cu o altă dependenţă, trebui să excludeţi dependenţa tranzitivă şi să declaraţi o altă dependenţă în loc.

De menţionat, că Maven nu descărca doar fişierul JAR al dependenţei, Maven descarcă de asemenea şi fişierul POM al dependenţei. Faptul că Maven descarcă fişierele POM adăugător faţă de artifacte îi permite să suporte dependenţele tranzitive, deoarece Maven consultă POM-urile dependenţelor pentru a găsi oricare alte dependenţe tranzitive. Aceste dependenţe tranzitive sînt apoi adaugate ca dependenţe a proiectului curent.

Dependenţe Opţionale

Dacă aveţi nevoie de câteva biblioteci pentru a compila proiectul dvs, dar nu doriţi ca toate bibliotecile să apară ca dependenţe tranzitive pentru proiectele care vor utiliza proiectul dvs ca dependenţă, atunci puteţi utiliza dependenţe opţionale aşa cum este arătat mai jos. De obicei aceasta situaţie poate apărea atunci cînd aplicaţia dvs suportă diferite implementări ale unui şi acelaşi API şi dvs lăsaţi utilizatorii să-şi aleagă singuri implementarea pe care o doresc.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.project</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0.0</version>
  <dependencies>
    <dependency>
      <groupId>org.othercompany</groupId>
      <artifactId>project-a</artifactId>
      <version>1.2.0</version>
      <optional>true</optional>
    </dependency>
    <dependency>
      <groupId>net.bigcompany</groupId>
      <artifactId>project-b</artifactId>
      <version>2</version>
      <optional>true</optional>
    </dependency>
  </dependencies>
</project>

Odată ce aţi declarat aceste dependenţe ca opţionale, sînteţi obligat să le includeţi în mod explicit în cadrul proiectului care depinde de my-project. De exemplu, dacă a-ţi scris o aplicaţie care depinde de my-project şi doriţi să folosiţi project-b ca implementare, atunci va trebui să adăugaţi următoarea configurare pentru proiectului dvs:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.project</groupId>
  <artifactId>my-application</artifactId>
  <version>1.0.0</version>
  <dependencies>
    <dependency>
      <groupId>com.company.project</groupId>
      <artifactId>my-project</artifactId>
      <version>1.0.0</version>
    </dependency>
    <dependency>
      <groupId>net.bigcompany</groupId>
      <artifactId>project-b</artifactId>
      <version>2</version>
    </dependency>
  </dependencies>
</project>

Referinţe către Proprietăţi

POM-ul poate include referinţe la proprietăţi precedate de semnul dolarului şi înconjurate de două acolade. Spre exemplu, priviţi la următorul POM:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.project</groupId>
  <artifactId>project-a</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
  <build>
    <finalName>${project.groupId}-${project.artifactId}</finalName>
  </build>
</project>

Când Maven citeşte POM-ul, el înlocuieşte referinţele la proprietăţi cu valorile acestora. În exemplul de mai sus finalName va fi evaluat în com.company.project-project-a. Aici noi am personalizat numele fişierului JAR generat prin adăugarea elementului finalName în configurarea de build a proiectului. Cu finalName egal cu com.company.project-proiect-a, build-ul va produce un fişier JAR în target/com.company.project-project-a.jar.

Maven pune la dispoziţie trei variabile implicite care pot fi folosite pentru a accesa variabilele de mediu şi sistem, informaţii din POM şi setările Maven:

env - expune variabile de mediu şi sistem care la rîndul lor sînt expuse de către sistemul de operare sau shell. De exemplu, o referinţă la ${env.PATH} într-un POM Maven va fi înlocuită cu valoarea variabilei de mediu $PATH (sau %PATH% în Windows).
project - expune POM-ul în întregime. Puteţi utiliza punctul (.) pentru a crea calea de referinţă către valoarea unui element din POM. De exemplu, în această secţiune am folosit groupId şi artifactId pentru a seta elementul finalName. Sintaxa pentru aceste referinţe a fost: ${project.groupId}-${project.artifactId}.
settings - expune informaţiile despre setările Maven. Puteţi utiliza punctul (.) pentru a crea calea de referinţă către valoarea unui element din fişierul settings.xml. De exemplu ${settings.offline} face referinţă la valoarea din elementul offline în <user_home>/.m2/settings.xml.

În plus faţă de cele trei variabile implicite, puteţi face referinţă la proprietăţile de sistem Java precum şi orice proprietăţi personalizate definite în POM sau într-un profil de build:

Proprietăţile de sistem Java - toate proprietăţile accesibile prin metoda getProperties() din java.lang.System sînt expuse ca POM proprietăţi. Câteva exemple de de proprietăţi sînt: ${user.name}, ${user.home}, ${java.home}, ${os.name}, etc. O listă completă a proprietăţilor de sistem Java pot fi găsite în Javadoc pentru clasa java.lang.System.
Proprietăţile personalizate - pot fi setate cu ajutorul elementului properties în pom.xml sau settings.xml, sau pot fi încărcate din fişiere externe. Dacă aţi stabilit o proprietate numită myproperty în pom.xml, atunci la această proprietate se poate face referinţă cu ${myproperty}. Mai jos este arătată sintaxa pentru definirea ${myproperty} = myvalue în POM:
```
<project>
  ...
  <properties>
    <myproperty>myvalue</myproperty>
  </properties>
  ...
</project>
```

Atît pentru astăzi. În următorul post vom descrie Plugin-urile şi Goal-urile Maven.

Introducere în Apache Maven 2, Partea 3 - Project Object Model (POM)

2009-05-16T17:00:00.002+03:00

Project Object Model (modelul obiect al proiectului) este un fişier XML, numit pom.xml, în care este definită structura proiectului, este configurat build-ul şi sînt definite relaţiile dintre proiecte. Un proiect Maven este caracterizat prin prezenţa fişierului pom.xml. Cînd Maven rulează, el consultă pom.xml pentru informaţii despre proiect. POM răspunde la astfel de întrebări ca: Ce fel de tip de proiect este acesta? Care este numele proiectului? Există careva personalizări pentru acest proiect?

Informaţia din POM este împărţită în 4 categorii:

Informaţia generală despre proiect - aceasta include numele proiectului, URL-ul proiectului, compania dezvoltatoare, lista de developeri şi colaboratori, licenţă proiectului.
Setările pentru build - În această secţiune se conţin toate personalizările proiectului. Se poate schimba locaţia fişierelor sursă, a testelor, se pot adăuga noi plugin-uri, se pot ataşa noi goal-uri (scopuri, obiective) ale plugin-urilor la ciclul de viaţă al proiectului, se pot personaliza parametrii pentru generarea paginii web a proiectului.
Mediul de build - constă din profiluri care pot fi activate pentru a fi utilizate în diferite medii (environment-uri). De exemplu, în timpul dezvoltării (development) se poate de ales de a face deploy pe un server de dezvoltare, iar în producţie de a face deploy pe un server de producţie.
Relaţiile POM-ului - Un proiect rareori este singur. De cele mai multe ori el depinde de alte proiecte, moşteneşte setări din POM-ul proiectului părinte, îşi defineşte propriile coordonate şi poate include şi sub-module.

Dacă dvs. doriţi să dezvoltaţi un proiect simplu, care produce un JAR, din sursele aflate în src/main/java, şi doriţi să rulaţi testele JUnit din src/test/java, atunci nu aveţi nevoie să personalizaţi nimic. Tot de ce aveţi nevoie în acest caz este cel mai simplu POM posibil, arătat mai jos:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.company.example</groupId>
    <artifactId>simple-project</artifactId>
    <version>1</version>
</project>

Dacă puneţi careva cod sursă în subdirectorul src/main/java şi rulaţi mvn install atunci în directorul target veţi avea generat fişierul simple-project-1.jar. [Click mai jos pentru a citi articolul în întregime]

Toate POM-urile proiectelor Maven extind acelaşi Super POM, care defineşte un set de valori şi setări implicite împărtăşite de toate proiectele. Super POM-ul este o parte din instalarea Maven, şi poate fi găsit în fişierul maven-2.1.0-uber.jar în ${M2_HOME}/lib. Dacă vă uitaţi în acest fişier JAR, veţi găsi un fişier numit pom-4.0.0.xml în pachetul org.apache.maven.project.

Deoarece POM-urile pot moşteni configurarea de la alte POM-uri, întotdeauna trebuie să ne gîndim la POM din punct de vedere al asocierii Super POM-ului cu POM-ul părinte şi în final cu POM-ul proiectului propriu zis. Maven începe cu Super POM şi apoi suprascrie configurarea implicită a acestuia cu unul sau mai multe POM-uri părinte. Apoi suprascrie configurarea primită cu POM-ul proiectului propriu zis. În final se ajunge la un POM efectiv, care este un amestec de diverse POM-uri. Dacă doriţi să vedeţi POM-ul efectiv al proiectului atunci puteţi să rulaţi goal-ul effective-pom al plugin-ului de ajutor Maven:

$ mvn help:effective-pom

După executarea acestei comenzi, ar trebui să vedeţi un POM mai mare, care expune pe lîngă ceea ce aţi definit dvs. explicit în POM, şi setările implicite de Maven (deoarece le va moşteni din Super POM). Plugin-urile şi goal-urile din Maven vor fi explicate în continuare într-un articol separat.

Coordonatele Maven

Cînd Maven execută un goal, fiecare goal are acces la informaţia definită în POM-ul proiectului. Cînd goal-ul jar:jar crează un fişier JAR, el accesează POM-ul pentru a găsi care trebuie sa fie numele fişierului JAR. Cînd goal-ul compiler:compile compilează sursele în byte-cod, el la fel accesează POM-ul pentru a vedea dacă nu sînt careva parametri definiţi pentru goal-ul compile. Toate goal-urile sînt executate în contextul POM-ului. Goal-urile nu sînt altceva decît nişte acţiuni pe care noi dorim să le aplicăm asupra unui proiect, iar proiectul este definit printr-un POM. POM-ul îi dă nume proiectului, îl înzestrează cu un set unic de identificatori (coordonate) şi stabileşte relaţii între acest proiect şi alte proiecte prin intermediul dependenţelor şi părinţilor.

Coordonatele Maven definesc un set de identificatori care pot fi folosiţi pentru a identifica un proiect, o dependenţă sau un plugin într-un POM Maven. Daţi să examinăm următorul POM simplu:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
                      http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.project</groupId>
  <artifactId>simple</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
  <name>simple</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

În POM-ul de mai sus am evidenţiat (rîndurile 6, 7, 8, 9) coordonatele Maven pentru acest proiect: groupId, artifactId, version şi packaging. Aceşti identificatori combinaţi împreună, plus încă unul classifier, care nu este menţionat în acest POM, reprezintă coordonatele unui un proiect în Maven. La fel ca şi în oricare alt sistem de coordonate, în Maven, coordonatele reprezintă o adresă pentru un anumit punct din "spaţiu". Maven face referinţă la un proiect prin coordonatele sale în cazul în care un proiect se referă la un alt proiect, fie ca dependenţă, plugin sau o referinţă către proiectul părinte. Coordonatele Maven sînt adesea scrise utilizând un 2 puncte(:) ca delimitator în următorul format: groupId:artifactId:packaging:version. În exemplul de POM de mai sus, coordonatele pentru proiect sînt org.company:simple:jar:1.0-SNAPSHOT.

Mai jos vom examina fiecare identificator în parte:

groupId - Grupul, compania, echipa, organizaţia, proiectul, sau un oricare alt grup. Convenţia pentru identificatoarele de grup este că ele încep cu numele invers al domen-ului organizaţiei care creează proiectului. De exemplu org.apache.maven este baza pentru toate groupId ale artifactelor produse de proiectul Apache Maven. Identificatoarele de grup, sînt transpuse în locaţii în repozitoriul Maven, de exemplu, org.apache.maven poate fi găsit în /org/apache/maven.
artifactId - este identificatorul principal al proiectului. Este un identificator unic în cadrul groupId care reprezintă un singur proiect. Nu pot exista două proiecte cu aceleaşi groupId şi artifactId. În timp ce "." (punct) este frecvent utilizat în groupId, aici ar trebui să se evite utilizarea lui. Acest lucru poate cauza probleme la analiza numelor.
version - versiunea proiectului. Proiectele care au fost puse în circulaţie deja (released), au o versiune fixă. În Maven versiunile sînt formate din următoarele părţi: versiunea majoră, versiunea minoră, versiunea incrementală şi calificativul. Într-o versiune, aceste părţi corespund următorului format:

<major version>.<minor version>.<incremental version>-<qualifier>
De exemplu, versiunea "1.3.5-beta-01" are o versiune majoră de 1, versiunea minoră 3, versiunea incrementală 5 şi un calificativ beta-01. Calificativul există pentru a reprezenta release-urile: alfa şi beta. Versiunile Maven pot de asemenea să conţină şi următorul şir de literali:
- SNAPSHOT - ceea ce semnifică faptul că un proiect este în prezent în curs de dezvoltare activ. Există posibilitatea de a configura Maven pentru a descărca periodic cea mai recentă versiune snapshot din repozitoriu. În cazul în care o versiune conţine şirul de caractere SNAPSHOT, atunci Maven va înlocui acest şir cu valoarea datei şi orei convertite la UTC (Coordinated Universal Time) atunci cînd se instalează sau se pune în circulaţie acest component. De exemplu, 1.4-SNAPSHOT se va transforma în 1.4-20090501-112507-1 dacă i-ar fi fost făcut deploy la 11:25 la 1 mai 2009 UTC.
- LATEST - se referă la cea mai recentă versiune snapshot sau la cea mai recentă versiune lansată (released) a unui anumit artifact din repozitoriu.
- RELEASE - se referă la cea mai recentă versiune care nu este snapshot a unui anumit artifact din repozitoriu.

Packaging-ul (formatul de ambalare) proiectului este de asemenea o componentă importantă în sistemul de coordonate Maven, dar acesta nu face parte din sistemul unic de identificatori ale unui proiect Maven. Setul groupId:artifactId:version face proiectul unic; nu poate exista un proiect cu aceleaşi trei groupId, artifactId, şi version.

packaging - tipul proiectului, implicit este jar. Descrie ce format produce proiectul respectiv. Un proiect cu packaging jar, produce un fişier JAR. Un proiect cu packaging war, produce o aplicaţie web.

Şi al patrulea, mai puţin folosit identificator:

classifier - se foloseşte atunci cînd este necesar pentru acelaşi proiect de a produce două artifacte separate, din motive tehnice. De exemplu, dacă se doreşte două artifacte JAR, unul compilat cu compilator Java 1.4 şi altul compilat cu compilator Java 6. În acest caz se poate utiliza calificativul pentru a produce două artifacte JAR în aceeaşi combinaţie groupId:artifactId:version.

În cazul în care proiectul este instalat în repozitoriul local Maven, acesta devine imediat disponibil pe plan local pentru orice alt proiect care doreşte să-l folosească. Tot ce trebuie de făcut este de-al adăuga ca pe o dependenţă folosind setul unic de coordonate Maven.

Repozitoriile Maven

Maven vine cu o locaţie implicită a remote repozitoriului http://repo1.maven.org/maven2, care este folosită pentru a descărca plugin-urile Maven de bază şi dependenţele. Maven descarcă plugin-urile şi dependenţele din repozitoriul remote la dvs. pe computer, într-un repozitoriu local. Odată ce Maven a descărcat un artifact din repozitoriul remote, el niciodată nu va mai avea nevoie să-l descarce încă o dată, deoarece Maven se uită întotdeaună mai întîi în repozitoriul local. În Windows XP repozitoriul local este situat în C:\Documents and Settings\USERNAME\.m2\repository, în sistemele din familia Unix el se afla în ~/.m2/repository.

Ce face un repozitoriu să fie un Maven repozitoriu? Un Maven repozitoriu este definit prin structura sa, un repozitoriu este o colecţie de artifacte ale proiectelor, stocate într-o structură şi un format care poate fi uşor înţeles de către Maven. Într-un repozitoriu Maven totul este stocat într-o structură de directoare, care se aseamănă foarte mult cu sistemul de coordonate Maven al unui proiect. Puteţi vedea această structură prin accesarea paginii repozitoriului central Maven http://repo1.maven.org/maven2/. Veţi vedea că un artifact cu coordonatele org.apache.velocity:velocity:1.6.2 este disponibil în sub-directoriul /org/apache/velocity/velocity/1.6.2/ într-un fişier numit velocity-1.6.2.jar. Standardul pentru un repozitoriu Maven este de a stoca un artifact în următoarea locaţie relativ cu directorul rădăcină al repozitoriului:

/<groupId>/<artifactId>/<version>/<artifactId>-<version>.<packaging>

Repozitoriul Maven este atît un cache local pentru artifactele descărcate din repozitoriul remote, cît şi un mecanism care permite proiectelor de a depinde unul de celălalt. Dacă aveţi 2 proiecte, A şi B, unde proiectul B depinde de artifactele produse de proiectul A, atunci Maven va prelua artifactele proiectului A din repozitoriul local atunci cînd va face build proiectului B.

Aici încheiem acest articol. În următorul post vom vorbi despre dependenţele proiectelor în Maven.

Introducere în Apache Maven 2, Partea 2 - Instalarea Maven

2009-05-13T22:30:00.011+03:00

În acest articol se va descrie cum de instalat Apache Maven pe computer-ul dvs. Mai jos sînt enumerate instrucţiunile care trebuiesc urmate:

Verificaţi instalarea Java - Încredinţaţi-vă că aveţi instalată cel puţin Java 5. Atît Java 5 cît şi Java 6 se potrivesc, dar cel mai bine e să aveţi ultima versiune disponibilă. Pentru a verifica ce versiune de Java aveţi instalată puteţi rula următoarea comandă:
C:\>java -version
java version "1.5.0_18"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_18-b02)
Java HotSpot(TM) Client VM (build 1.5.0_18-b02, mixed mode, sharing)
Descărcaţi Maven - Puteţi descărca Maven de pe pagina oficiala a proiectului Apache Maven http://maven.apache.org/download.html. Aveţi grijă să alegeţi ultima versiune disponibilă.
Instalaţi Maven - După ce l-aţi descărcat, alegeţi o locaţie şi despachetaţi fişierul arhivat descărcat. Apoi veţi avea nevoie să definiţi 2 variabile de sistem: PATH şi M2_HOME. Dacă lucraţi pe Windows, o puteţi face cu următoarele comenzi:
set M2_HOME=c:\apache-maven-2.1.0
set PATH=%PATH%;%M2_HOME%\bin
Rularea acestor comenzi în linia de comandă vă va permite să rulaţi Maven doar în sesiunea curentă, pentru a evita setarea lor de fiecare dată, le puteţi seta în Control Panel ca Environment Variables.

Dacă lucraţi pe un sistem de operare din familia Unix, atunci puteţi folosi următoarele comenzi:

export M2_HOME=/usr/local/apache-maven-2.1.0
export PATH=${M2_HOME}/bin:${PATH}
Testaţi instalarea - După ce aţi instalat Maven, îl puteţi testa rulînd mvn -version din linia de comandă pentru a vedea versiunea acestuia. Dacă instalarea a fost OK, atunci va trebui să vedeţi ceva de genul acesta:

C:\>mvn -version
Apache Maven 2.1.0 (r755702; 2009-03-18 21:10:27+0200)
Java version: 1.5.0_18
Java home: C:\Program Files\Java\jdk1.5.0_18\jre
Default locale: ro_RO, platform encoding: Cp1250
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Dacă nu puteţi vizualiza acest mesaj sau sistemul de operare nu poate găsi comanda mvn atunci ar trebui să verificaţi încă o dată dacă variabilele PATH şi M2_HOME sînt setate corect. [Click mai jos pentru a citi articolul în întregime]

Setarea de Proxy - Dacă aveţi acces direct la internet puteţi omite acest pas. Doar cei care folosesc un proxy pentru ieşirea în internet au nevoie să urmeze instrucţiunile de mai jos. Deoarece Maven are nevoie de Internet atunci cînd lucrează în modul cel mai optim, este nevoie de a-l configura pentru a şti ce proxy aveţi dvs. Pentru aceasta creaţi (sau dacă există deja modificaţi) fişierul <user_home>/.m2/settings.xml cu următorul conţinut:

<settings xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
          http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <proxies>
    <proxy>
      <id>myproxy</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.somewhere.com</host>
      <port>8080</port>
      <username>proxyuser</username>
      <password>somepassword</password>
    </proxy>
  </proxies>
</settings>

Fişierul <user_home>/.m2/settings.xml conţine setările specifice utilizatorului respectiv pentru autentificare, repositorii (repositories) şi alte lucruri care pot modifica comportamentul Maven.

Notă: Vom utiliză syntaxa <user_home> pentru a ne referi la directorul de pornire al utilizatorului. În sistemele de operare din familia Unix, directorul de pornire a utilizatorului este /home/USERNAME sau ~. În Windows XP directorul de pornire al utilizatorului este C:\Documents and Settings\USERNAME. De acum înainte dvs. trebuie să interpretaţi locaţiile de genul <user_home>/.m2/settings.xml în dependenţă de sistemul dvs. de operare.

Ştergerea (uninstall) Maven - Dacă doriţi să ştergeţi Maven de pe computer-ul dvs, atunci va trebui să ştergeţi directorul unde a-ţi instalat Maven şi să eliminaţi variabilele de sistem. De asemenea va fi nevoie să ştergeţi şi directorul <user_home>/.m2 care reprezintă repositorul local Maven.

Aici încheiem acest articol. În următorul post vom descrie Project Object Model (POM).

Introducere în Apache Maven 2, Partea 1 - Ce este Maven?

2009-05-12T20:38:00.001+03:00

Acesta este primul articol dintr-o serie dedicată Apache Maven 2. Menirea acestora este de a face o introducere în privinţa acestui tool open source (instrument cu codul sursă deschis) care este pe larg utilizat atît de majoritatea proiectelor Java Open Source, cît şi de celelalte. Vreau să menţionez că se va vorbi doar despre Apache Maven 2, şi chiar dacă în context cifra 2 nu este specificată, se are în vedere anume Maven 2. Versiunea Maven 1 nu este în scopul acestei introduceri.

Deci, ce este Maven? Cea mai mare parte a utilizatorilor Maven vor spune că Maven este un instrument pentru build, în timp ce definiţia de pe pagina oficială a proiectului Apache Maven http://maven.apache.org spune că Maven este un instrument pentru management al proiectelor. Deci, care este diferenţa? Un instrument pentru build se axează în principal pe preprocesare, compilare, ambalare (packaging), testare şi distribuţie. Un instrument pentru management, cum ar fi Maven, în plus faţă de capacităţile de build pe care le are, şi care sunt cu mult mai simple şi uşoare în folosire, mai prevede de asemenea şi un ciclu de viaţă al proiectului, un sistem de management al dependenţelor, poate rula rapoarte, genera o pagină web a proiectului, facilitează comunicarea între membrii echipei de lucru prin oferirea unei interfeţe comune, şi multe alte facilităţi.

Mai jos sînt enumerate principiile de bază pe care le prevede Maven: [Click mai jos pentru a citi articolul în întregime]

Convenţia în favoarea Configuraţiei (Convention over Configuration) - Convenţia în favoarea Configuraţiei este un concept foarte simplu. Sistemele, bibliotecile şi framework-urile trebuie să definească valori implicite rezonabile. Fără a necesita configurare inutilă, sistemele ar trebui simplu să lucreze. Maven include acest concept prin furnizarea unor setări implicite pentru proiecte. Fără nici o personalizare şi configurare, codul sursă se presupune a fi în: src/main/java şi a resurselor în: src/main/resources. Testele se presupun a fi în: src/test şi proiectul se asumă să producă un fişier JAR. Maven presupune că se doreşte ca byte-codul să fie compilat în target/classes şi apoi să se creeze un fişier JAR repartizabil (distributable) în target. Maven aplică un set comun de convenţii pentru compilarea codului sursă, ambalarea fişierelor pentru repartizare, generarea de pagini web, şi multe alte procese. Dacă se urmează convenţiile, Maven va necesita un efort minim, aproape de zero - doar plasaţi sursele în directoarele corecte şi Maven va avea grijă de restul.
O interfaţă comună - Înainte ca Maven să propună o interfaţă unică pentru a face build la produsele software, fiecare proiect avea sistemul său propriu de build. Fiecare developer care dorea să facă build la proiect trebuia să se întrebe un şir de întrebări. Ce va produce build-ul? De ce biblioteci şi librării am nevoie? De unde să le descarc? Unde trebuie să le pun? Ce comandă sau goal (scop) trebuie să rulez? Developerii aveau nevoie de ceva timp ca să înveţe cum să facă build la un proiect sau altul. În prezent însă, atunci cînd vedem că un proiect foloseşte Maven, putem presupune că vom putea fară mari probleme să descarcăm sursele şi să-i facem build cu mvn install.
Abordare declarativă - Totul în Maven se face într-un mod declarativ folosind Project Object Model (POM) (modelul obiect al proiectului). Noi nu doar compilăm codul sursă, ci creăm o descriere a proiectului şi atributelor acestuia, în acelaşi timp alocîndu-i proiectului un set unic de coordonate. Care este licenţa proiectului? Cine dezvoltă şi contribuie la acest proiect? Care sînt proiectele de care depinde acest proiect? Tot ce trebuie de făcut este de creat fişierul pom.xml cu descrierea proiectului şi de pus sursele în directoarele predefinite. Maven va avea grijă de restul.
Refolosirea logicii de build - Maven a abstractizat sarcinile comune de build în plugin-uri, care sînt menţinute centralizat şi share-uite (împărţite, împărtăşite) universal către toţi. Nucleul Maven este destul de simplu şi limitat. El nu ştie altceva decît să parse-ze (analizeze) cîteva documente XML şi să menţină cîteva cicluri de viaţă a proiectului şi cîteva plugin-uri. Maven a fost creat astfel încît să delege marea responsabilitate către un set de plugin-uri Maven. Cea mai mare parte a acţiunilor în Maven se întâmplă în plugin-uri, care se ocupă de lucruri ca compilarea codului sursă, ambalarea bytecode-ului, publicarea paginilor web, precum şi orice altă activitate de care este nevoie într-un build.

Deci, pentru a răspunde la întrebarea iniţială: Maven este multe lucruri pentru multe persoane. Este un set de standarde şi o abordare specifică în dezvoltarea proiectelor software. Maven este un instrument foarte capabil, care poate fi în acelaşi timp simplu sau complex, în dependenţă de ce este nevoie. Din acest motiv, de cele mai multe ori există mai multe moduri pentru a realiza aceeaşi sarcină.

Aici încheiem acest articol. În următorul post va fi descris cum se poate de instalat Apache Maven.

Notă: Imaginea de la începutul articolului a fost luată de pe http://commons.wikimedia.org/wiki/File:Maven_logo.gif şi este licenţiată sub licenţa Apache License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0.

Cum de creat articole extensibile (expandable posts) pe Blogger

2009-05-10T18:42:00.004+03:00

Mai întîi o explicaţie, ce se înţelege prin articole extensibile. Acestea sunt articolele formate din 2 părţi: rezumatul articolului sau introducerea şi conţinutul propriu zis al articolului. Pe pagina principală a blog-ului, vizitatorul vede doar rezumatul articolului. Pentru a citi articolul în întregime vizitatorul poate face click pe link-ul care se afla îndată după rezumat şi atunci întregul articol va fi afişat.

Mai jos voi descrie cum se poate de făcut acest lucru pe Blogger. Ceea ce voi descrie eu de fapt este un rezumat şi o traducere în română al unui articol chiar de pe pagina de ajutor a Blogger-ului, o puteţi găsi aici http://help.blogger.com/bin/answer.py?hl=en&answer=42215.

Mai jos sînt prezentaţi paşii ce trebuie urmaţi:

Încredinţaţi-vă că aveţi activate paginile de postări. Pentru aceasta mergeţi la Setări -> Arhivare -> Activaţi paginile de postări (Settings -> Archiving -> Enable Post Pages) şi alegeţi Da. Nu uitaţi să salvaţi.
Mergeţi la Aspect -> Editaţi HTML (Layout -> Edit HTML) şi Extindeţi şabloanele control (Expand Widget Templates) (faceţi click pe check-box-ul cu acelaşi nume).

Căutaţi următoare linie: <title><data:blog.pageTitle/></title> şi îndată după ea adăugaţi următoarea secvenţă de cod:

<style>
  <b:if cond='data:blog.pageType == "item"'>
    span.fullpost {display:inline;}
  <b:else/>
    span.fullpost {display:none;}
  </b:if>
</style>

Căutaţi mai apoi următoarea linie: <data:post.body/> şi îndată după ea adăugaţi următoarea secvenţă de cod:

<b:if cond='data:blog.pageType != "item"'>
  <a expr:href='data:post.url'>Citeşte articolul în întregime</a>
</b:if>

Salvaţi şablonul.
Mergeţi la Setări -> Formatare -> Şablon pentru postare (Settings -> Formatting -> Post Template) şi adăugaţi următorul lucru:
```
Rezumatul
<span class="fullpost">Restul conţinutului</span>
```
Salvaţi.

Acum de fiecare dată cînd veţi începe a scrie un nou post (articol), el va conţine deja acele ultime 2 linii de cod adăugate în Şablonul pentru postare. Nu vă rămîne decît să plasaţi rezumatul şi restul conţinutului în locurile corespunzătoare. De asemenea puteţi merge şi edita articolele deja existente, lăsînd o parte din text ca introducere, iar cealaltă incluzînd-o între tag-urile <span class="fullpost">...</span>.

Articole asociate, legate, înrudite (related posts) pe Blogger

2009-05-09T23:43:00.007+03:00

Un nou articol nu la temă :-) Oare cînd vei începe Zagorneanu să scrii o dată despre programare? Ştiu, ştiu, va fi şi asta în curînd. Pînă atunci un scurt post despre cum de pus pe Blogger un widget (în limba noastră româna ar fi ceva de genul "o drăcărie" ;-)) care ar afişa lista articolelor care sînt asociate (legate, înrudite) cu articolul curent. O chestie foarte bună pentru cititor, atunci cînd caută careva informaţie, dar şi pentru tine, deoarece menţii mai mult timp cititorul pe site.

Mai întîi aş vrea să explic ce se înţelege prin articole asociate. În contextul nostru acestea nu sînt alt ceva decît articolele care sunt etichetate cu aceeaşi etichetă (etichetă = label). Deci pentru a putea folosi această nouă funcţionalitate articolele dvs. trebuie sa fie etichetate corespunzător.

Există 2 modalităţi de a instala această funcţionalitate pe Blogger: una foarte simplă şi alta simplă :-) Să începem cu cea foarte simplă.

Adăugarea articolelor asociate ca widget separat. Aceasta înseamnă ca lista cu articolele asociate (etichetate cu aceeaşi etichetă) va fi afişată undeva într-o parte (dreapta, stînga, josul paginii) în dependenţă de design-ul paginii. Pentru aceasta accesaţi următoarea pagina http://brps.appspot.com/, coborîţi un pic mai jos în pagină pînă la alineatul Installation şi face-ţi click pe butonul albastru-oranj pe care scrie Add to Blogger. Atîta tot. Acum aranjaţi widget-ul unde doriţi în pagină şi salvaţi. Trebuie de menţionat că lista cu articolele asociate nu va apărea pe prima pagină a blog-ului dvs, în schimb, ea va fi afişată cînd veţi deschide un articol. Atunci veţi vedea lista cu articolele etichetate la fel.
Adăugarea articolelor asociate sub (dedesubt) articol. În acest mod lista cu articolele asociate va fi afişată sub articol, ceea ce după părerea mea e mai bine şi cade mai bine în vizorul cititorului. Pentru aceasta va fi nevoie să efectuaţi următorii paşi:
1. Mergeţi la Setări -> Aspect -> Editaţi HTML (Settings -> Layout -> Edit HTML) şi Extindeţi şabloanele control (Expand Widget Templates) (faceţi click pe check-box-ul cu acelaşi nume).
2. Căutaţi următoare linie:
```
<div class='post-footer-line post-footer-line-3'/>
```
3. Adăugaţi o line nouă, cea evidenţiată (ultima linie din exemplu), aşa cum este arătat mai jos. Fiţi atenţi, linia noua trebuie adăugată după următorul </div> ce urmează linia de cod găsită.
```
<div class='post-footer-line post-footer-line-3'/>
...
</div>
<div id='related_posts'/>
```
4. Mergeţi la sfîrşitul şablonului şi înainte de </body></html> adăugaţi următoarele 2 rînduri aşa cum este arătat mai jos:
```
<script src='http://www.google.com/jsapi'/>
<script src='http://brps.appspot.com/brps.js' type='text/javascript'/>
</body>
</html>
```
  Ca şi în primul caz, lista articolelor asociate nu va fi afişată pe pagina principală a blog-ului, dar în dedesubtul fiecărui articol, atunci cînd acesta este deschis.

Pentru mai multe informaţii în privinţa personalizării (titlul, numărul de articole afişate, folosirea CSS) puteţi accesa următoarea pagină http://code.google.com/p/brps/

P.S. Puteţi vedea acest widget în acţiune chiar în dedesubtul acestui articol.

Cum setăm o pictogramă favorită (favicon) pe Blogger

2009-03-08T15:30:00.014+02:00

Cu scopul de a-mi personaliza blog-ul, a-m hotărît să-mi schimb pictograma (iconiţa, favicon-ul) blog-ului. În continuare voi descrie cum de făcut acest lucru. Deci, pentru a schimba pictograma blog-ului, dvs aveţi nevoie de parcurs următorii paşi:

1. Să vă găsiţi o pictogramă pe plac, cu mărimea 16x16 în format .png sau .ico (pictograma în format .ico trebuie să folosească gama de 256 de culori)

2. Să încărcaţi pictograma respectivă pe un site public unde fiecare are acces. De exemplu Google Sites. Cum de creat un site nou pe Google Sites şi mai apoi încărcat fişiere pe el am descris în articolul precedent.

3. Mergeţi la Setări -> Aspect -> Editaţi HTML (Settings -> Layout -> Edit HTML) şi imediat după rîndul de mai jos

<title><data:blog.pagetitle/></title>

adăugaţi următorul lucru:

<link href='http://adresadvs/pictogramadvs.png' rel='shortcut icon' type='image/x-icon'/>

unde adresadvs este adresa unde a-ţi încărcat pictograma, iar pictogramadvs este numele pictogramei. (dacă pictograma este în format .ico, în adresă veţi specifica respectiv pictogramadvs.ico)

În final trebuie să aveţi următorul lucru:

<title><data:blog.pagetitle/></title>
<link href='http://adresadvs/pictogramadvs.png' rel='shortcut icon' type='image/x-icon'/>

4. Salvaţi şablonul blog-ului şi faceţi click pentru a vizualiza schimbările. Pictograma specificată de dvs trebuie sa apară.

P.S. Pictograma folosită de mine a fost descărcată de pe site-ul http://www.faviconsr.us/

Cum instalăm şi utilizăm SyntaxHighlighter 2.0 pe Blogger

2009-03-02T23:26:00.037+02:00

Deoarece majoritatea articolelor publicate pe acest blog vor avea legătură cu IT(Information Technology), şi cum IT-ul fără de cod nu poate exista, am hotărît să-mi instalez pe blog un modul care va evidenţia şi colora codul sursă publicat în articole.

După o căutare pe Google am dat de SyntaxHighlighter, o bibliotecă scrisă în JavaScript menită să evidenţieze şi să coloreze codul sursă. De notat că SyntaxHighlighter începînd cu 1 martie 2009 este licenţiat sub licenţa LGPL3, ceea ce ne permite să-l utilizăm liber şi gratis.

Curios este faptul că pînă la 1 martie 2009 SyntaxHighlighter era licenţiat sub licenţa LGPL2.1 dar cu o excepţie adăugată de autorul bibliotecii, prin care acesta cerea utilizatorilor care folosesc această bibliotecă pe paginile lor web sau în produsele acestora să doneze în mod obligatoriu cît îi lasă inima pentru susţinerea şi dezvoltarea de mai departe a acestui proiect. Acest lucru este complet incompatibil cu licenţa LGPL, fapt care probabil nu a fost observat de către autor. Îmbucurător este faptul că autorul s-a auto-sesizat şi acum donaţiile nu mai sunt obligatorii ci doar binevenite. Aşa că dacă utilizaţi şi vă place acest produs, susţine-ţi autorii acestei minunate biblioteci donînd cît consideraţi necesar.

În acest articol voi descrie cum de instalat şi mai apoi folosit SyntaxHighlighter 2.0 pe Blogger. De menţionat faptul ca versiunile precedente mai sunt găzduite pe Google Code cu toate că în prezent acesta nu mai este un proiect activ.

1. De ce avem nevoie de SyntaxHighlighter.

Pentru a demonstra utilitatea evidenţierii şi colorării codului sursă este suficient să aducem următorul exemplu.

Aşa arată fragmentul de cod fără a utiliza SyntaxHighlighter. Fragmentul de cod este inclus între <pre>...</pre>

public class HelloWorld {
public static void main(String[] args) {
 System.out.println("Hello World!");

 System.out.print("Echo: ");
 for(int i = 0; i < 5; i++) {
     System.out.print("Hello! ");
 }
}
}

Astfel arată fragmentul de cod cu utilizarea SyntaxHighlighter. Fragmentul de cod este inclus între <pre class="brush: java; highlight:[6, 7, 8]">...</pre> astfel specificînd limbajul şi numerele rîndurilor pe care dorim să le selectăm.

public class HelloWorld {
public static void main(String[] args) {
 System.out.println("Hello World!");

 System.out.print("Echo: ");
 for(int i = 0; i < 5; i++) {
     System.out.print("Hello! ");
 }
}
}

Este simplu şi arată mult mai bine nu-i aşa? Pe lîngă evidenţierea şi colorarea cuvintelor cheie, numerotării rîndurilor, mai există şi posibilitatea selectării individuale a rîndurilor pentru a atrage atenţia cititorului sau pentru a face referire la ele din text. [Click mai jos pentru a citi articolul în întregime]

2. Cum instalăm SyntaxHighlighter.

Pentru început este nevoie de a descărca SyntaxHighlighter de aici şi de a-l încărca pe blog-ul dumneavoastră. Dar aşa cum Blogger nu oferă posibilitatea încărcării fişierelor(cu excepţia pozelor şi filmuleţelor) va trebui să-l încărcăm pe un site public unde oricine are acces.

O altă opţiune este folosirea versiunii găzduite pe site-ul SyntaxHighlighter. Mai multe detalii aici. Dacă alegeţi această opţiune atunci puteţi trece direct la pasul următor (nr. 3), dar totuşi ar fi bine sa urmăriţi comentariile şi observaţiile ce ţin de performanţă care se vor aduce în continuare.

Pentru a găzdui SyntaxHighlighter eu am ales Google Sites, unde există posibilitatea de a crea un site gratis în doar cîteva clipe. În plus există posibilitatea de a păstra aici fişiere şi de a face referire la ele de pe blog. Spaţiul oferit de Google Sites este de 100MB.

Biblioteca SyntaxHighlighter constă din două mape scripts şi styles. Anume conţinutul lor şi trebuie încărcat. Mapa scripts conţine următoarele fişiere:

clipboard.swf - este un fişier Flash folosit de către SyntaxHighlighter pentru a copia textul în clipboard atunci cînd utilizatorul apasă butonul Copy to clipboard de pe toolbar. Dacă doriţi această funcţionalitate atunci acest fişier trebuie încarcat, dacă nu, atunci ignoraţi-l.
shCore.js - este nucleul bibliotecii. Trebuie încărcat obligatoriu.
shLegacy.js - este un proxy pentru fragmentele de cod publicate folosind versiunile mai vechi ale SyntaxHighlighter. Mai multe detalii aici. Dacă nu aţi mai folosit SyntaxHighlighter pînă acum puteţi ignora acest fişier.
shBrush*.js - sunt fişiere pensule pentru fiecare limbaj susţinut de bibliotecă. Acestea din urmă conţin informaţia despre cuvintele cheie, structura şi comentariile limbajelor respective. Este nevoie de încărcat doar fişierele pentru limbajele pe care le veţi folosi pe blog-ul dvs.

Mapa styles conţine următoarele fişiere:

shCore.css - este fişierul CSS de bază. Trebuie încărcat obligatoriu.
shTheme*.css - SyntaxHighlighter 2.0 a întrodus noţiunea de temă sau aspect. Aceasta permite schimbarea aspectului şi palitrei de culori utilizate de SyntaxHighlighter. Mai multă informaţie aici. Este nevoie de încărcat doar fişierul cu tema pe care doriţi să o utilizaţi pe blog-ul dvs.
*.png - imaginile folosite de SyntaxHighlighter. Trebuie încărcate obligatoriu.

NOTĂ DE PERFORMANŢĂ: După ce vor fi încărcate pe Google Sites, şablonul blog-ului dvs va trebui modificat pentru a include toate aceste fişiere. Ca urmare, browserul dvs va trebui să descarce toate aceste fişiere, ceea ce înseamnă în jur de 20 de conexiuni adăugătoare. Cu toate că aceste fişiere sunt foarte mici, fiecare conexiune nouă este costisitoare. Sfatul meu este să combinaţi toate fişierele shBrush*.js în unul singur, şi să-l numiţi shBrushAll.js, astfel veţi reduce considerabil numărul conexiunilor necesare pe care browserul dvs va trebui sa le facă şi veţi îmbunătăţi performanţa.
Acelaşi lucru este şi cu fişierele CSS. Alegeţi tema pe care o veţi folosi pe blog-ul dvs şi combinaţi acest fişier cu shCore.css. De exemplu daca utilizaţi shThemeDefault.css atunci fişierul primit de la combinarea shCore.css cu shThemeDefault.css poate fi numit shCoreThemeDefault.css.
În această privinţă am făcut chiar un test, în care am măsurat timpul de încărcare al unei pagini pe Blogger care includea fiecare shBrush*.js în parte şi al altei pagini care includea doar shBrushAll.js. Iată rezultatele: 20 de secunde contra a 4 secunde. O îmbunătăţire de 5 ori. Timpul de încărcare a fost măsurat cu ajutorul serviciului Stopwatch. După părerea mea 20 de secunde pentru o pagină care practic nu avea nimic pe ea e prea mult.
Aşa că gîndiţi-vă bine înainte de a folosi versiunea găzduită pe site-ul SyntaxHighlighter, deoarece în acest caz veţi fi nevoit să includeţi fiecare fişier în parte, ceea ce înseamnă un timp mai mare de încărcare a paginilor dvs.

Pentru a instala SyntaxHighlighter pe Google Sites veţi avea nevoie să parcurgeţi următorii paşi:

a) Înregistraţi-vă şi creaţi un site nou. Fiţi siguri ca aţi ales opţiunea de a-l face public, adică oricine va putea accesa acest site.

b) Creaţi o pagină web nouă accesînd butonul din imagine.

c) Alegeţi setările astfel cum este arătat în imaginea de mai jos.

d) Creaţi o altă pagină web şi alegeţi setările astfel cum este arătat în următoarea imagine. Fiţi atenţi la alegerea locaţiei. Pagina scripts trebuie sa fie inclusă în syntaxhighlighter. Pentru a specifica locaţia folosiţi link-ul Alege o altă locaţie (Choose a different location)

e) Unul cîte unul, încărcaţi toate fişierele din mapa scripts pe noua pagină web scripts, folosind butonul din imagine. (Dacă aţi hotărît combinarea tuturor fişierelor shBrush*.js în unul singur shBrushAll.js atunci încărcaţi-l doar pe cel din urmă. În orice caz nu uitaţi să încărcaţi şi shCore.js)

ATENŢIE: Google Sites nu permite încărcarea fişierelor JavaScript (extensia .js), din acest motiv înainte de a încarca fişierele, schimbaţi-le extensia în .txt

f) Repetaţi paşii d) şi e) pentru mapa styles. Folosiţi aceleaşi setări schimbînd doar numele cu styles.

g) În final trebuie sa aveţi următoare ierarhie de pagini. (În această imagine este arătată doar ierarhia paginilor, fără fişierele pe care acestea le conţin)

3. Cum configurăm SyntaxHighlighter.

După ce aţi încarcat toate fişierele, urmează modificarea şablonului blog-ului dvs cu scopul de a include toate aceste fişiere. Pentru aceasta mergeţi la Setări -> Aspect -> Editaţi HTML (Settings -> Layout -> Edit HTML) şi imediat după tag-ul <head> adăugaţi fişierul CSS de bază şi cel ce ţine de tema aleasă de dvs, aşa cum este arătat mai jos (în exemplul de mai jos am folosit tema shThemeDefault.css, dar dvs puteţi folosi oricare alta):

<head>
<link type="text/css" rel="stylesheet" href="http://sites.google.com/site/numeledvs/syntaxhighlighter/styles/shCore.css" />
<link type="text/css" rel="stylesheet" href="http://sites.google.com/site/numeledvs/syntaxhighlighter/styles/shThemeDefault.css" />
...

Apoi trebuie adăugat shCore.js urmat de toate fişierele pensule pe care le veţi folosi pe blog-ul dvs (în exemplul de mai jos extensia fişierelor este .js pentru a nu crea confuzii în cazul în care cineva a hotărît să găzduiască SyntaxHighlighter pe un site altfel decît Google Sites, dvs însă trebuie să o schimbaţi în .txt în cazul în care aţi încărcat fişierele pe Google Sites):

<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shCore.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushJScript.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushJava.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushSql.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushXml.js"></script>

Şi în sfîrşit trebuie invocată funcţia SyntaxHighlighter.all() care practic şi face tot job-ul:

<script type="text/javascript">
SyntaxHighlighter.config.bloggerMode = true;
SyntaxHighlighter.all();
</script>

Ţin să atenţionez asupra importanţei liniei de cod subliniate. Aceasta din urmă trebuie adăugată atunci cînd folosim SyntaxHighlighter pe Blogger. Aceasta se datorează faptului ca Blogger foloseşte <br> pentru trecerea la rînd nou, şi fără setarea acestui parametru toate <br> vor fi afişate în fragmentele de cod. Iată un exemplu. Aşa va arăta fragmentul de cod cu specificarea bloggerMode = true;

Iar aşa fără specificare:

În final totul împreună trebuie să arate aşa:

<head>
<link type="text/css" rel="stylesheet" href="http://sites.google.com/site/numeledvs/syntaxhighlighter/styles/shCore.css" />
<link type="text/css" rel="stylesheet" href="http://sites.google.com/site/numeledvs/syntaxhighlighter/styles/shThemeDefault.css" />

<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shCore.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushJScript.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushJava.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushSql.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushXml.js"></script>

<script type="text/javascript">
 SyntaxHighlighter.config.bloggerMode = true;
 SyntaxHighlighter.all();
</script>
...

Sau dacă mi-aţi urmat sfatul şi aţi combinat fişierele împreună, atunci rezultatul final va arăta aşa:

<head>
<link type="text/css" rel="stylesheet" href="http://sites.google.com/site/numeledvs/syntaxhighlighter/styles/shCoreThemeDefault.css" />

<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shCore.js"></script>
<script type="text/javascript" src="http://sites.google.com/site/numeledvs/syntaxhighlighter/scripts/shBrushAll.js"></script>

<script type="text/javascript">
 SyntaxHighlighter.config.bloggerMode = true;
 SyntaxHighlighter.all();
</script>
...

ATENŢIE: Nu uitaţi să schimbaţi numeledvs în toate adresele cu numele pe care l-aţi dat site-ului în momentul în care l-aţi creat.

4. Cum utilizăm SyntaxHighlighter.

Simplu de tot. SyntaxHighlighter caută în pagină toate tag-urile <pre> care conţin atributul class formatat într-un mod special. Acest format este acelaşi ca şi al atributului style în HTML. Unicul parametru obligator este brush care trebuie setat cu unul dintre sinonimele fişierelor pensulă incluse de dvs. Acesta din urmă va specifica limbajul fragmentului de cod utilizat.

Iată un caz tipic de utilizare:

<pre class="brush: java">
System.out.println("Hello World!");
</pre>

IMPORTANT: Fiţi atenţi la fragmentele de cod ce conţin caracterele < şi > Acestea trebuie înlocuite cu < şi respectiv >

De asemenea pe lîngă parametrul obligatoriu brush, mai putem specifica şi alţi parametri. Lista întreagă cu toţi parametri şi descrierea acestora o găsiţi aici.

Iată un exemplu mai sofisticat:

<pre class="brush: java; ruler: true; toolbar: false; first-line: 10; highlight: [11, 12]; font-size: 125%">
System.out.println("Hello World 1!");
System.out.println("Hello World 2!");
System.out.println("Hello World 3!");
</pre>

Parametrii adiţionali care au fost specificaţi au dus la următoarele:

Vizualizarea riglei.
Ascunderea toolbar-ului.
Numerotarea rîndurilor începe de la 10.
Liniile 11 şi 12 sunt selectate.
Specificarea mărimii font-ului de 125%.

Un lucru important este faptul că există posibilitatea redefinirii valorilor implicite a acestor parametri. De exemplu, dacă doriţi să ascundeţi toolbar-ul în toate fragmentele din toate articolele dvs, atunci puteţi adăuga următoarea linie de cod selectată, înaintea invocării SyntaxHighlighter.all(); aşa cum este arătat mai jos:

<script type="text/javascript">
SyntaxHighlighter.config.bloggerMode = true;
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
</script>

Aceasta va seta valoarea implicită a parametrului toolbar. Ca rezultat toate fragmentele de cod care nu au specificat explicit valoarea acestui parametru, vor utiliza aceasta valoare, ceea ce va duce la ascunderea toolbar-ului.

După cum vedeţi SyntaxHighlighter este foarte simplu şi uşor în utilizare şi în acelaşi timp oferă o gamă largă de posibilităţi.

Utilizare plăcută :-)

Cuvînt înainte

2009-03-01T11:47:00.011+02:00

După aproape 3 ani de la crearea acestui blog şi publicarea primului mesaj de test, m-am convins că ar fi bine sa scriu cîte ceva pe acest blog, care de altfel a fost conceput ca unul personal, dar pe care din mai multe motive nu am postat nimic :-)

Zis şi făcut, de astăzi voi începe publicarea unor articole, care vor ţine mai mult de domeniul în care activez, şi anume tehnologii informaţionale. Desigur vor fi publicate şi articole ce ţin nemijlocit de internet, web şi chiar de utilizarea unor produse software.

Motivul principal pentru publicarea articolelor este de a-mi crea on-line un şir de notiţe, analize, sfaturi, investigaţii, etc.

Într-un ceas bun!

Test

2006-08-29T10:53:00.011+03:00

Test