In questo articolo ci preoccupiamo di configurare un progetto GXT usando Maven ed Eclipse come IDE. Per configurare Eclipse occorre scaricare la versione Juno (4.2) , installare il GWT plugin usando l’update site disponibile all’url http://dl.google.com/eclipse/plugin/4.2 e installare m2eclipse tramite l’update site disponibile all’url http://download.eclipse.org/technology/m2e/releases.

Configurato Eclipse realizziamo il nostro primo progetto avvalendoci di maven e dell’archetipo gwt-maven-plugin tramite la direttiva

mvn archetype:generate -DarchetypeGroupId=org.codehaus.mojo -DarchetypeArtifactId=gwt-maven-plugin -DarchetypeVersion=2.5.1 -DgroupId=it.finazzo -DartifactId=sencha -Dversion=1.0

Tramite questa direttiva maven crea un progetto che supporta l’alberatura di GWT. Durante l’esecuzione della direttiva specifichiamo il nome del modulo principale (nel mio caso Application), ovvero la classe che implementa l’entry point, il punto di accesso alla nostra applicazione.

A questo punto tramite la direttiva mvn gwt:eclipse possiamo generare i file necessari ad effettuare l’import in Eclipse.

Resta da aggiungere la dipendenza da GXT, agendo sul pom.xml e sul file xml associato al modulo entry point.

Aggiungiamo la versione di GXT da usare tramite il tag <gxt.version>3.0.1</gxt.version>

Specifichiamo il repository  da cui scaricare i sorgenti di GXT

<repositories>
<repository>
<id>sencha-commercial-release</id>
<name>Sencha commercial releases</name>
<url>https://maven.sencha.com/repo/commercial-release/</url>
</repository>
</repositories>

E infine aggiungiamo la dipendenza da GXT tramite il blocco

<dependency>
<groupId>com.sencha.gxt</groupId>
<artifactId>gxt</artifactId>
<version>${gxt.version}</version>
</dependency>

Una volta aggiunta la dipendenza rendiamola attiva nel progetto eclipse tramite la direttiva mvn gwt:eclipse che si preoccuperà di scaricare le nuove librerie.

Resta da modificare il modulo Application.gwt.xml per rimuovere il tema di GWT e innestare l’eredità da GXT tramite il comando

<inherits name="com.sencha.gxt.ui.GXT" />

e linkare il file reset.css nella pagina Application.html tramite la direttiva

<link rel="stylesheet" type="text/css" href="/joomla/Application/reset.css">

Nel file Application.java sostituiamo il gwt-button con un oggetto sencha com.sencha.gxt.widget.core.client.button.TextButton  e se abbiamo operato correttamente tramite la direttiva mvn gwt:run possiamo verificare che il progetto venga avviato correttamente.

Incominciamo con il creare il nostro progetto maven con la direttiva

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

La direttiva crea una cartella contenente contenente il file pom.xml e la cartella src contenente i sorgenti e i file junit per l’esecuzione dei test.

Lanciamo la direttiva mvn eclipse:eclipse per creare i file necessari ad un progetto eclipse ed importiamo il progetto nel nostro workspace.

A questo punto agganciamo il plugin responsabile della compilazione dei sorgenti jrxml, tipici di JasperReports. Tale plugin prevede la presenza di una cartella jasperreports sotto src/main. Creiamo la cartella e modifichiamo il pom inserendo la dichiarazione del plugin.

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>jasperreports-maven-plugin</artifactId>
      <executions>
        <execution>
          <goals>
            <goal>compile-reports</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

A questo punto lanciamo la direttiva mvn compile per verificare la correttezza delle nostre operazioni. Se avete sbagliato a posizionare la cartella il plugin vi ricorderà il percorso esatto.

Restano da definire le dipendenze dalla versione di jasperReports da usare. Per farlo è sufficiente specificare la dipendenza a livello di progetto e a livello di plugin, nel nostro caso ho scelto la versione 4.0.2

<dependencies>
    <dependency>
      <groupId>net.sf.jasperreports</groupId>
      <artifactId>jasperreports</artifactId>
      <version>4.0.2</version>
    </dependency>
  </dependencies>

Creiamo il nostro file jrxml nella cartella jasperreports e lanciamo la direttiva mcn compile. A questo sotto la cartella target avremo il nostro file compilato e pronto all’uso.

Il vantaggio di questa soluzione è di aver all’atto della compilazione tutti i report in linea con i file jrxml presenti nel progetto.

Qui trovate i sorgenti dell’articolo.

Iniziamo con il creare il progetto parent tramite la direttiva base

mvn archetype:create -DgroupId=it.finazzo.esempio -DartifactId=progettoModulare

Adesso dobbiamo configurare i moduli all’interno del nostro progetto. Per farlo è sufficiente modificare il tag di packaging specificando pom al posto di jar e indicando i moduli tramite il tag modules.

<modules>
<module>../front-end</module>
<module>../back-end</module>
</modules>

Creiamo il progetto relativo al front-end realizzato in flex. In questo caso ci avvaliamo di flexmojos, un set di plugin realizzati da Sonatype per consentire in maven la compilazione, l’ottimizzazione e il testing di componenti flex. Mister Sonatype ha messo a disposizione una serie di archetipi per soddisfare le nostre esigenze: la creazione di una libreria, la creazione di una applicazione flex e la creazione di un progetto progetto suddiviso in moduli swc, swf e flex. Nel nostro caso ci avvaliamo del secondo archetipo e scegliamo la versione stable che è , nel momento in cui scrivo, la 3.9.

mvn archetype:generate -DarchetypeRepository=http://repository.sonatype.com/content/groups/flexgroup -DarchetypeGroupId=org.sonatype.flexmojos -DarchetypeArtifactId=flexmojos-archetypes-application -DarchetypeVersion=3.8 -DgroupId=it.finazzo.progettoModulare -DartifactId=front-end

Generato il progetto occorre modificare il pom per includere il repository maven di Sonatype per consentire il download di tutti i componenti necessari alla compilazione. Potete includere il repository all’interno del pom file dello specifico progetto o nel file settings.xml per renderlo disponibile per tutti i progetti.

<repositories>
<repository>
<id>flex-mojos-repository</id>
<url> http://repository.sonatype.org/content/groups/flexgroup/</url>
</repository>
</repositories>

Infine specifichiamo il path del flash player stand alone per poter eseguire i test tramite la variabile flashPlayer.command

<properties>
<flashPlayer.command>\path\flashplayer_10_sa_debug.exe</flashPlayer.command>
</properties>

Creiamo il progetto del back-end realizzato in spring-ws 2.0. Usiamo la direttiva che abbiamo usato in uno dei precedenti articoli per generare il nostro back-end.

mvn archetype:create -DarchetypeGroupId=org.springframework.ws -DarchetypeArtifactId=spring-ws-archetype -DarchetypeVersion=2.0.2.RELEASE -DgroupId=it.finazzo.progettoModulare -DartifactId=back-end.

All’interno del progetto back-end specifichiamo la dipendenza dal progetto front-end tramite il tag dependencies

<dependency>
<groupId>it.finazzo.progettoModulare</groupId>
<artifactId>front-end</artifactId>
<version>1.0-SNAPSHOT</version>
<type>swf</type>
</dependency>

e includiamo il plugin flexmojos-maven-plugin responsabile di copiare gli swf generati nella root del nostro back-end.

<plugin>
<groupId>org.sonatype.flexmojos</groupId>
<artifactId>flexmojos-maven-plugin</artifactId>
<version>3.5.0</version>
<executions>
<execution>
<goals>
<goal>copy-flex-resources</goal>
</goals>
</execution>
</executions>
</plugin>

Per verificare il corretto funzionamento lanciamo la direttiva mvn package sul progetto parent. I moduli verranno compilati e assemblati nell’ordine dichiarato, ottenenendo il seguente ouput:

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] progettoModulare ...................................... SUCCESS [0.779s]
[INFO] front-end Flex ........................................ SUCCESS [16.670s]
[INFO] back-end Spring-WS Application ........................ SUCCESS [11.676s]

Qui trovate i file necessari per fare il vostro progetto modulare.

L’uso di archetipi consente di definire dei progetti standard, la cui alberatura e le cui classi rispondono agli standard scelti, e che sono alla base deii progetti da essi derivati.

La generazione dell’archetipo si basa sulla direttiva archetype:create-from-project.

Tale direttiva genera l’archetipo basato sul progetto nella directory target/generated-sources/archetype.

Accediamo alla directory dell’archetipo e lanciamo la direttiva mvn:install.

Tale direttiva consente l’installazione dell’archetipo nel catalogo locale a disposizione per la creazione di altri progetti.

Per sfruttare l’archetipo appena generato creiamo una nuova directory e dopo esserci spostati al suo interno usiamo la seguente direttiva

mvn archetype:generate -DarchetypeCatalog=local

Tale direttiva consente attraverso una procedura guidata la creazione del nostro progetto basato sull’archetipo generato.

Il passo successivo è condividere il nostro archetipo su un repository maven all’interno della nostra azienda in modo da consentire a tutti gli utenti la creazione agevole di nuovi progetti.

E’ possibile installare sonar come server indipendente o come web application su un container Tomcat. Si appoggia ad un database per le statistiche estratte. Presenta un database embedded Apache Derby, ma Sonar consiglia di appoggiarsi ad un database più robusto. Sonar supporta i seguenti database:

• MySQL 5.1.x
• Oracle 10g XE
• PostgreSQL
• MS SqlServer 2005

Per configurare un database diverso da Apache Derby occorre agire sul file di configurazione e agire sui parametri:

• sonar.jdbc.url : URL del database
• sonar.jdbc.driver : driver
• sonar.jdbc.user : username (default ‘sonar’)
• sonar.jdbc.password : password (default ‘sonar’)

Nel nostro caso installeremo sonar come web application su un tomcat. Scaricate la distribuzione zip, scompattatela e lanciate il bat presente nella directory war.

Una volta creato il file .war fate il deploy sul vostro tomcat e accertatevi che il context sia attivo. Il war si preoccuperà di generare in automatico tutte le tabelle utili sul vostro database.

A questo punto non resta che integrare il plugin nel nostro progetto maven. L’integrazione avviene in 3 step:

• Inserire il puntamento al server nel file settings.xml di maven. Il file si trova sotto la conf di maven.

<profile>
<id>sonar</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation> 
<properties> 
<sonar.host.url>http://localhost:9000/sonar</sonar.host.url> </properties> 
</profile>

•  Inserire il plugin nel pom file

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>1.0-beta-2</version> <-- da usare con maven 2.x
</plugin>

•  infine lanciare la seguente direttiva

mvn sonar:sonar

Dopo l’elaborazione della direttiva possiamo accedere alla dashboard di sonar e vedere i risultati

Il repository centrale di Maven è disponibile all’url http://repo1.maven.org/maven2, come definito nel file settings.xml.

Maven crea un repository in locale sotto la home dell’utente al fine di evitare accessi alla rete inutili. Nel processo di gestione del progetto Maven verifica in locale l’esistenza della libreria desiderata e in caso negativo interroga il repository centrale.

E’ possibile aggiungere altri repository, agendo sul file settings.xml oppure sul pom file del progetto.

La gestione di nuovi repository si rende necessaria quando occorre integrare librerie sviluppate internamente alla nostra organizzazione o ad oggi non ancora supportate dalla comunity di Maven.

Chi scrive usa artifactory, un ottimo repository open source realizzato da JFrog Ltd.

Sostanzialmente è una web application che implementa tutti i servizi necessari per la gestione di un repository Maven, dalla gestione delle librerie agli snapshot, dalla possibilità di importare e esportare i repository o solo alcuni rami di libreria.

Per l’installazione e l’utilizzo rimando al sito di artifactory, dove c’è un ottimo manuale wiki.

Per integrarlo all’interno del nostro progetto è sufficiente aggiungere nel pom file la sezione repositories

<repositories>
<repository>
<id>sviluppo-releases</id>
<url>http://x.y.z.w:port/artifactory/libs-releases-local</url>
</repository>
</repositories>

 Con questo articolo si chiude la presentazione di Maven. Per approfondimenti rimando al sito di Maven e all’ottimo tutorialpresente sul sito di Mokabyte.

• mvn –version

permette di inidividuare la versione di maven utilizzata, comodo per verificare se l’installazione è andata a buon fine.

• mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

crea una directory di nome my-app con all’interno il pom file base, l’alberatura del progetto e degli unit test.

• mvn eclipse:eclipse

crea i file di progetto per consentire l’import all’interno di eclipse

• mvn eclipse:clean

rimuove i file di progetto di eclipse

• mvn compile

genera tutti i file .class secondo l’alberatura del progetto

• mvn clean

elimina i file generati

• mvn package

assembla il progetto nel formato desiderato

E’ importante notare che è possibile lanciare in sequenza i comandi

• mvn clean compile package

E’ possibile integrare un sistema per la gestione del tracking dei difetti. Tramite il tag issueManagement è possibile inserire le coordinate del sistema di tracking.

<issueManagement>
    <system>Bugzilla</system>
    <url>http://127.0.0.1/bugzilla/</url>
</issueManagement>

E’ possibile integrare un sistema per la Continuous Integration

<ciManagement>
    <system>continuum</system>
    <url>http://127.0.0.1:8080/continuum</url>
    <notifiers>
      <notifier>
        <type>mail</type>
        <sendOnError>true</sendOnError>
        <sendOnFailure>true</sendOnFailure>
        <sendOnSuccess>false</sendOnSuccess>
        <sendOnWarning>false</sendOnWarning>
        <configuration><address>continuum@127.0.0.1</address></configuration>
      </notifier>
    </notifiers>
  </ciManagement>

Un sistema per la gestione di una mailing list

<mailingLists>
    <mailingList>
      <name>User List</name>
      <subscribe>user-subscribe@127.0.0.1</subscribe>
      <unsubscribe>user-unsubscribe@127.0.0.1</unsubscribe>
      <post>user@127.0.0.1</post>
      <archive>http://127.0.0.1/user/</archive>
      <otherArchives>
        <otherArchive>http://base.google.com/base/1/127.0.0.1</otherArchive>
      </otherArchives>
    </mailingList>
  </mailingLists>

Un sistema per il software configuration come svn

<scm>
    <connection>scm:svn:http://127.0.0.1/svn/my-project</connection>
    <developerConnection>scm:svn:https://127.0.0.1/svn/my-project</developerConnection>
    <tag>HEAD</tag>
    <url>http://127.0.0.1/websvn/my-project</url>
  </scm>

E’ possibile aggiungere altri repository, oltre quello previsto dal sistema Maven http://repo1.maven.org/maven2/

Il repository è il sistema che contiene tutti gli artifatti necessari per la gestione del progetto. Possono essere aggiunti altri repository, che contengono libreria necessarie per la gestione del progetto.

La sezione base presenta la seguente struttura:

<build>
  <defaultGoal>install</defaultGoal>
  <directory>${basedir}/target</directory>
  <finalName>${artifactId}-${version}</finalName>
  <filters>
    <filter>filters/filter1.properties</filter>
  </filters>
  ...
</build>

•  Il tag defaultGoal indica l’obiettivo che deve eseguire Maven una volta lanciato. Normalmente viene indicato tramite linea di comando
• Il tag directory indica dove viene salvato il prodotto di Maven
• il tag flnalName indica come viene nominato il prodotto di Maven
• Il tag filter individua i file filter. Sono dei file che contengono variabili che vengono applicate durante la fase di compilazione e packaging.

Altra sezione fondamentale è quella dedicata alle risorse, ovvero quei file che non vengono compilati ma inglobati nel bundle generato.

<resources>
      <resource>
        <filtering>false</filtering>
        <directory>${basedir}/src/main/plexus</directory>
        <includes>
          <include>configuration.xml</include>
        </includes>
        <excludes>
          <exclude>**/*.properties</exclude>
        </excludes>
      </resource>
    </resources>

• Il tag filtering indica se applicare le variabil contenute nei file filtri.
• Il taf directory indica dove si trovano le risorse
• Il tag include permette di selezionare alcune risorse, specificando un pattern
• Il tag exclude permette di escludere alcune risorse, specificando un pattern

La dipendenza viene gestita tramite il tag dependency. Tale tag permette di individuare gli elementi necessari per la gestione del progetto.

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.0</version>
      <type>jar</type>
      <scope>test</scope>
      <optional>true</optional>
    </dependency>
</dependencies>

La tripletta groupId, artifactId e version identifica univocamente la libreria all’interno del repository Maven.

Il tag type individua il formato della libreria, se non è indicato vale jar.

Il tag scope invidua per quale fase del progettoè necessaria la libreria. Può assumere vari valori:

• compile –> indica che la libreria è necessaria per la compilazione. E’ il valore di default qualora non venga indicato.
• provided –> indica che la libreria è necessaria per la compilazione, ma che viene fornita dalla JDK o dal container.
• runtime –> indica che la libreria non è necessaria per la compilazione, ma solo per l’esecuzione.
• test –> indica che la libreria è usata solo in fase di testing.
• system –> è simile al provided, ma in tal caso è compito dell’utente indicare dove reperire la libreria tramite il tag systemPath

Il tag optional indica che la libreria è opzionale qualora si volesse aggiungere in un nuovo progetto la dipendenza da questo progetto.

Tramite il tag exclusion è possibile rimuovere delle specifiche dipendenze dagli artifatti aggiunti.

L’ereditarietà permette di creare nuovi POM file che ereditano le relazioni definite in un super POM. Il tutto viene gestito tramite il tag parent. Ecco un esempio.

<parent>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>my-parent</artifactId>
    <version>2.0</version>
</parent>

E’ possibile anche definire un progetto come aggregato di altri progetti. L’aggregazione viene gestita dal tag module. In tal modo è possibile tramite un solo pom gestire il ciclo di vita di più sottoprogetti.

<modules>
    <module>my-project</module>
    <module>another-project</module>
</modules>