Avoid XML Schema restrictions

I am back on XML Schema design and I do really like it !

One of the challenge that I am facing now is including or not the UBL metalanguage in my schemas (see some video on the oasis website), an Oasis standard, as you can deduce.

As you can see from this file:

http://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/common/UBL-UnqualifiedDataTypes-2.1.xsd

UBL metalanguage has elements which are based on the UN/CEFACT elements, see:

http://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/common/CCTS_CCT_SchemaModule-2.1.xsd

So as you can see UN/CEFACT has ComplexType which are extended by adding optional attributes, while the UBL elements are sometime restrictions  on the attributes (by making them required) and sometimes the elements are just extended giving a freedom in a later moment to choose what to add.

Independently from  the current problem, it happens that we might not need all the attributes or simply all the elements for our schema.

So either we add restrictions or we copy the elements that we need in our schema but simplified.

Adding restrictions can be possible in two ways:

1) Restrict on the patterns, like the max length of an element, they are so called facets, see: http://www.w3.org/TR/xmlschema-0/#SimpleTypeFacets

2) Restrict on the number of elements or attributes, in the case of the attributes  we need to make them prohibited

Conceptually both are restrictions based on an another type and this creates a problem in Object Oriented languages, like Java (hence the tittle of this post) which supports extensions (at the end a restriction is a sort of extension of a base object with some changes).

Jaxb is the official standard used for databinding XML elements to Java objects which relies on XJC for the conversion. Such standard adds Java annotations to associate XML elements to Java objects. Further, Jaxb relies on the validator of the marshaller by using the setSchema() method, see for example the post of Blaise Doughan, so in any moment you can validated your object against the schema to be sure before sending out your xml message.

For the facets, Jaxb doesn’t create annotations, there is still an open issue where 2 subgroups are working to solve it but still none of them are officially approved:

Other data bindings work on simple restrictions like enumerations (see Jibx) or numeric type and enumerations (see Xmlbeans, now archived).

You need also to consider that facets can change in the future (the max length could be extended from 100 characters to 200), so which impact has changing the xml schema? Since Jaxb doesn’t generate annotations for facets you don’t need to change the java objects but other databindings might be.

For the restriction on the the number of elements/attributes this CANNOT be reflected in a Object Oriented language because it is not possible to restrict an extended class on inherited properties. Therefore I suggest to copy simplified elements (by keep only those mandatory and removing the optionals), in this way:

  1. you have less dependency
  2. the developer has less method generated (just those needed)
  3. you keep compatibility at the minimum if you want to convert the copied object into the original objects

Therefore I would recommend to avoid restrictions if possible, you can keep them for the sake of validation but you need to think about the impact on the objects generated with the databinding libraries. Such recommandation is also expressed by the HP XML schema best practices (search for “restrictions for complex types”) and in Microsoft xml schema design pattern.

 

 

 

JAXB and the root element

Recently I helped a friend to implement the client of a web service using Axis2 and Tomcat, developing the client first and the jsp after. After testing the web service with SoapUI we started to develop the client with Eclipse.

The problem with this web service is that the body of the method is an entire xml string contained in a CDATA element, not only for for the request but also for the answer, of course this creates problem to generate the java objects from the wsdl file since the element is not defined as XML.

Luckily we received the xsd files so we generated the java classes with JAXB data binding which is implemented, and it can be executed, through the application xjc that you can find inside the bin folder of the Java Virtual Machine. Note that JAXB is the default databinding of Apache Cxf.

JAXB worked nicely but we had the problem to extract from the xml string the node container which needed to be declared as root element, in other words you need to use the @XMLRootElement annotation otherwise you can have the exception:

unexpected element (…) , Expected elements are (none).

when you unmarshal (from string to java object) the element.

 

Galleon, un forum in Coldfusion

Si avete letto bene Coldfusion; benchè esso sia tecnologia proprietaria realizzata da Adobe, esistono diverse implementazioni libere e tra queste troviamo Railo.

Railo, come Adobe Coldfusion, è una applicazione Java che compila il codice coldfusion in classi java, la cui ultima versione 3.1 è rilasciata con licenza LGPL 2 come progetto di Jboss.

Railo può essere scaricato per i diversi sistemi operativi (Windows, Max, Linux), con Jetty o Resin o senza come un war file che deve essere copiato in un application server.

Io ho scaricato la versione 3.1.2 con Jetty per prova il che significa che dovete semplicemente eseguire il file start e recarvi all’indirizzo localhost:8888.

Una volta cambiata la password per motivi di sicurezza vi ritroverete nel pannello di amministrazione. Per installare Galleon dovete:

  1. creare un database MySQL che potete fare velocemente da Xampp
  2. andare nel pannello di amministrazione di Railo e sotto la voce Services -> Datasources creare un datasource di tipo mysql che si collega al database creato (utente e password sono quellli di MySQL)
  3. andare nel pannello di amministrazione di Railo e sotto la voce Extension – Applications spuntare la voce Galleon (forum hostato su RiaForge e creato da Raymond Camden) e cliccare sul pulsante install, il quale (dopo aver accettato la licenza Apache) vi redirige ad un form che dovete riempire (inserite il campo email che si trova nel mezzo del form anche se non richiesto altrimenti avrete una eccezione) e poi potete accedere al login di Galleon.

Una volta inseriti username/password (admin/admin) vi ritroverete di fronte al front-end, per il backend dovete andare su: http://localhost:8888/forum/admin/

Nel pannello di amministrazione di Galleon troverete un menu a sinistra dove potete:

  • creare Conferences, Forum, Thread, Messages
  • modificare i valori che avete inserito nella fase di installazione
  • gestire gruppi e utenti
  • consultare statistiche; se non avete configurato un server SMTP avrete un errore coldfusion per le statistiche generali, sono interessanti le stastitiche sulle parole cercate (magari si potrebbe connettere con Solr..)

Buona esplorazione !

Webclient for SVN, Hudson e Artifactory

Salve a tutti, in questi giorni mi sono addentrato ancora nel mondo del continuous integration perchè sto lavorando su un progetto in Java, gestito in outsourcing, dove aiuto un gruppo di sviluppatori ad utilizzare strumenti di sviluppo che facilitano il lavoro quali un sistema di continuos integration.

Sono partito da un progetto con subversion installato su una macchina e so che nel progetto usano Jboss con JDK 1.5 (ancora non so perchè)

Su un’altra macchina remota vado e installo JDK 1.5.0.22, Ant 1.7.1, Maven 2.2.1 (fino ad ora (2 mesi di progetto) hanno usato solo Ant e vorrebbero passare a Maven), Jboss 5.1.0, Webclient for SVN 3.1.0 e Artifactory 2.1.2.

Piccola nota: volevo usare Sventon ma l’ultima versione aveva problemi con le librerie e le precedenti mi davano anch’esse problemi.

Non sapete cosa è Artifactory ??? Allora è possibile che siete ancora freschi su Maven (non è che io non lo sia :-) )

Artifactory è una applicazione web che permette di gestire repository Maven, sviluppata in Java e rilasciata con licenza LGPL 3.0. L’applicazione è realizzata da JFrog Ltd, una società privata isreliana.

Strutturalmente si poggia su Apache Jackrabbit per l’implemetazione delle specifiche JSR 170 per il cosiddetto Java Content Repository (anche altri content manager come Nuxeo si appoggiano su Jackrabbit).

Piccola nota: la JSR 170 (rilasciata nel 2005) è seguita dalla JSR 283 da poco rilasciata (25 Settempre 2009) ed entrambe sono condotte da David Nuescheler, CTO della società svizzera Day Software.

Inoltre Artifactory si basa su Apache Lucene per indicizzare i file e Apache Wicket per l’interfaccia utente.

Ora l’applicazione è rilasciata come standalone ma esiste la versione war che può essere deployata su un application server e quindi l’ho messa su Jboss insieme ad Hudson e Webclient for SVN (questi 2 li ho poi legati con il plugin di hudson per Polarion che permette di linkare la lista di file modificati ai file presenti sul webclient e si possono anche vedere le differenze con le versioni precedenti).

La struttura è basata anche su database, di default Apache Derby ma che può essere cambiato (vedi anche qui).

A parte il fatto che Artifactory permette di base una autenticazione LDAP, quello che lascia senza parole è la semplicità di uso (andrebbe confrontato con Nexus ma non ne ho tempo, di sicuro nella versione base manca LDAP (anche se ho scoperto di recente che esiste un plugin di terze parti) e di sicuro gli sviluppatori hanno realizzato una bella guida a maven e un plugin per Eclipse). Una volta andato su

http://localhost:8080/artifactory

e loggato, sono andato sul pannello amministrativo e nella sezione repository ho creato un repository locale dove fare il deploy dei propri jar file e un repository virtuale in cui aggiungo quello locale più tutti i remoti quali quello di Maven, Jboss ecc ecc. Fatto ! Ora potete generare anche la sezione del file settings.xml da aggiungere nel vostro progetto Maven.

Per una vecchia guida vi rimando qui. Per un confronto con Nexus e Archiva vi rimando a questo link (attenzione è scritto dallo stesso autore della guida su Artifactory ma sembra serio)

Buon maven a tutti !

Nota: Webclient for SVN si basa su Subversion 1.4 (con versioni successive ho avuto problemi perchè usa un SVNKit vecchio che non posso aggiornare perchè c’è una particolare classe non più presente nelle ultime versioni), potete trovare Subversion 1.4 qui:

http://downloads-guests.open.collab.net/servlets/ProjectDocumentList?folderID=6

Netbeans 6.5.1 e Openfire 3.6.4

Oggi ho provato Openfire 3.6.4 un server XMPP scritto in Java rilasciato con licenza GPL.

Stavo pensando di fornire un servizio di chat e mi sono ricordato che quelli di Sun avevano messo il supporto a Netbeans chiamato Developer Collaboration ma come ho scritto in un precedente post c’erano problemi di compatibilità che ora sembrano superati con le nuove versioni di Netbeans.

Ho dapprima scaricato il file dal sito della Ignite Realtime (versione Mac OS X poi su Win), una volta installato me lo sono ritrovato in /usr/local/openfire. Dentro la cartella bin ho trovato il file openfire.sh ha cui ho dato i permessi di esecuzione ma che ho eseguito da root. Ho poi eseguito il file e sono andato nel mio browser (firefox) all’indirizzo:

http://localhost:9090

Tra le lingue a disposizione trovate Ceco, Tedesco, Inglese, Spagnolo, Francese, Olandese, Polacco, Portoghese Brasiliano, Sloveno e Cinese Semplificato.

Dopo le lingue impostate il vostro dominio con le porte 9090 e 9091. Dopo dovete scegliere se usare un database interno o esterno (potete scegliere tra MySQL, Oracle, Microsoft SQLServer, PostgreSQL, IBM DB2).

Ho scelto MySQL, ho impostato l’indirizzo di localhost e nel frattempo ho creato il database perchè Openfire non lo crea.

Ho poi scelto per il profilo di usare il database, alternativamente si può scegliere LDAP o ClearSpace. Infine ho poi impostato email e password di amministratore.

Alla fine della procedura avete necessità di riavviare il server perchè altrimenti la pagina di login non funzionerà !

Noto che il plugin search non è installato sulla versione di Openfire per Mac (su Win si, devo vedere su linux) e procedo ad installarlo.

Dopo di che come spiegato in questo post (ma anche nel primo link che vi ho dato) occorre creare una nuova Group chat; invece di usare “conference” ho creato “myconference”.

Poi sono andato su Netbeans, ho installato il plugin Developer Collaboration, e ho creato un nuovo account chiedendo di registrarmi sul server, alla fine della procedura di registrazione dovreste poter vedere il nuovo account sul server. Dovreste poi autenticarvi senza nessun problema.

Per fare una prova di chat ho usato Pidgin o Spark (rilasciato dalla stessa azienda) creando un utente sul server e loggandomi una volta con Pidgin e una volta con Spark. La chat diciamo che va, quando è l’utente su Pidgin che apre la conversazione con il client su Netbeans si vede un po’ di codice XML il contrario invece no. Occorre provare tra 2 istanze di Netbeans.

C’è da dire che Netbeans punta su Kenai per il servizio di chat vedi qui.

Nota: una mia collega usava QIP come chat client, per poterla riuscire a loggare sono dovuto andare in Jabber options->Advanced->Server option>Disable SASL authentication; notavo infatti che all’atto di scambiare il digest MD5 c’erano problemi.

Installazione veloce di Alfresco su Glassfish

Ho cominciato a valutare l’idea di installare un Document Management System per un progetto a cui sto lavorando e poichè  in un altro progetto ho notato che hanno installato Liferay che si appoggia su Alfresco ho pensato di cominciare con Alfresco appunto.

Avendo Glassfish 2.1 installato in locale, ho scaricato il file war di Alfresco dal seguente link:

http://process.alfresco.com/ccdl/?file=release/labs/build-1526/alfresco-labs-war-3Stable.tar.gz&a=y&s=n&t=y

che permette di scaricare la versione stabile di Alfresco Labs 3.1. Fate il deploy dell’applicazione da Glassfish ma non lo lanciate perchè altrimenti ricevete errore HTTP Status 503.

Come difatti spiegato nel wiki e in questo post che ho trovato, dovete creare manualmente il database su cui Alfresco si poggia altrimenti avete l’errore che vi ho detto.

Di default Alfresco si basa su MySQL e, sempre di default, il suo database è alfresco con username alfresco e password alfresco, tutto questo lo potete vedere nel file /alfresco/WEB-INF/classes/alfresco/repository.properties perciò usando PHPMyAdmin potete creare velocemente database e utente, fatto cio’ troverete alfresco all’indirizzo:

http://localhost:8080/alfresco

L’amministratore per default ha username admin e password admin (potete cambiarla una volta loggati oppure prima di creare il database andate nel file /alfresco/WEB-INF/classes/alfresco/web-client-config.xml ).

Buona esplorazione !

PS: ora sarei curioso come funziona l’integrazione con Drupal.

PS2: alternativamente stavo pensando a KnowledgeTree che si può integrare con Process Maker.

Web.xml e HTTPS: proteggere le vostre pagine JSP

Sono ai primi passi con JSP e sto creando una pagina di login per l’autenticazione, una di quelle banali con username e password che vanno verificate.

A parte impostare il form con method=”POST” mi sono chiesto come abilitare https per offrire una comunicasione sicura. Niente di più semplice, probabilmente nella vostra applicazione web vi ritrovate il web.xml già creato dal vostro IDE e che potete modificare.

Il file web.xml è chiamato deployment descriptor perchè esso descrive come la vostra applicazione composta da diversi file (o risorse) viene raggiunta dall’esterno, non solo in termini di URL ma anche in termini di sicurezza.

Come abbiamo capito il deployment descriptor è un file xml che è descritto da uno schema, l’ultima versione la 2.5 la trovate qui:

http://java.sun.com/xml/ns/javaee

cercate la voce Servlet Deployment Descriptor Schema.

Un semplice esempio lo trovate qui:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>

Potete notare la versione 2.5, lo schema web-app_2_5.xsd, il parametro di timeout (0 significa no time out) e il welcome file che contiene il file index.jsp che deve essere il primo ad essere visitato.

Per quanto riguarda la sicurezza, se vogliamo aggiungere la protezione su tutte le risorse e fare in modo che altre entità, terze persone, non vedano il contenuto trasmesso (in altre parole SSL), dovremo aggiungere appena prima del tag </web-app> la seguente configurazione:


<security-constraint>
<web-resource-collection>
<web-resource-name>secure</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

è molto importante sapere che:

  • potete specificare più di un security constraint, vedere qui un esempio; nell’esempio potete notare che si può scegliere se applicare la sicurezza al solo metodo POST o GET o a tutti i metodi specificati nel protocollo HTTP 1.1
  • l’url-pattern /* indica tutte le pagine che si trovano subito dopo la / nell’URL, potete anche dire /main/* tutte le pagine che si trovano dopo /main/ nella loro url
  • il livello CONFIDENTIAL dice che altre entità non possono vedere il messaggio trasmesso, il sotto livello è INTEGRAL per cui il messaggio non può essere modificato in transito e NONE quando non si vuole alcuna garanzia sul trasporto

Ora non dovete far altro che il deploy della stessa applicazione e andare sul link http della vostra applicazione e verrete rediretti su HTTPS (accettando il certificato).

La versione 2.5 è destinata ad essere seguita dalla 3.0 come descritto dalla JSR 315 che introdurrà diversi miglioramenti tra cui l’uso delle annotazioni nelle servlet rendendo vano l’uso del file web.xml, ma tutto cio’ si accadrà su J2EE 6 e quando i diversi servlet-container saranno pronti per interpretarli.

Inserire una licenza nei vostri progetti con Netbeans

Oggi stavo programmando con Netbeans per esercitarmi con le pagine Jsp e ho scoperto che dalla versione 6.0 è data la possibilità di inserire in automatico la licenza nei file.

Il tutto è possible grazie ai template che tramite parametri costruiscono per voi il layout della classe; ad esempio quando create una nuova classe vi viene chiesto il suo nome e il package a cui appartiene, nome e package sono passati al template per costruire la nuova classe appena creata.

Se andate nel menu Tools -> Templates -> Java -> Java class e cliccate su Open in Editor avete:


<#assign licenseFirst = "/*">
<#assign licensePrefix = " * ">
<#assign licenseLast = " */">
<#include "../Licenses/license-${project.license}.txt">


<#if package?? && package != "">
package ${package};
</#if>
/**
*
* @author ${user}
*/
public class ${name} {
}

Come vedete la prima parte è dedicata alla licenza mentre la seconda per dichiarare il package e la classe. Per quanto riguarda la licenza viene specificato che la prima riga sarà indicata da /* (utilizzando il parametro licenseFirst), ogni riga verrà preceduta da * (parametro licensePrefix) e l’ultima parte deve finire con */ (parametro licenseLast), il tutto per diventare un commento nel codice Java.

Come vedete c’è anche il parametro project.license che dovete settare. Supponiamo ora che vogliamo aggiungere la licenza EUPL andiamo nella finestra dei Files e nella cartella nbproject trovate il file project.properties, alla fine del file aggiungete il parametro:

project.license=EUPL

Andiamo a reperire la nota EUPL nel sito:

http://www.osor.eu/eupl/how-to-use-the-eupl

dove c’è il link al PDF Guideline for users and developers EUPL Guideline

a pagina 17 (Eupl 1.1) trovate la nota di testo, che dovete copiarvi in un editor di testo e trasformare ad esempio nel seguente modo:


<#if licenseFirst??>
${licenseFirst}
</#if>
${licensePrefix}Copyright ${date?date?string("yyyy")} {organization}
${licensePrefix}
${licensePrefix}Licensed under the EUPL, Version 1.1 or – as soon they
${licensePrefix}will be approved by the European Commission - subsequent
${licensePrefix}versions of the EUPL (the "Licence");
${licensePrefix}You may not use this work except in compliance with the
${licensePrefix}Licence.
${licensePrefix}You may obtain a copy of the Licence at:
${licensePrefix}
${licensePrefix}http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1
${licensePrefix}
${licensePrefix}Unless required by applicable law or agreed to in
${licensePrefix}writing, software distributed under the Licence is
${licensePrefix}distributed on an "AS IS" basis,
${licensePrefix}WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
${licensePrefix}express or implied.
${licensePrefix}See the Licence for the specific language governing
${licensePrefix}permissions and limitations under the Licence.
<#if licenseLast??>
${licenseLast}
</#if>

e salvate il file con il nome license-EUPL.txt

Nota: la variabile date è una delle variabili predefinite per i template, vedere qui.

Ora andate in Tools -> Licenses e fate click sul pulsate Add per selezionare il file, vedrete che ora vi compare tra le licenze a disposizione.

Nota: il file viene poi salvato nella cartella utente di sistema, nel mio caso (sotto mac)

/Users/emidiostani/.netbeans/6.1/config/Templates/Licenses

Come però avete notato, il file contiene anche la variabile organization; questa variabile l’ho definita in Tools->Templates ->User Configuration Properties -> User.properties, scrivendo ad esempio:

organization=Unisys

e semplicemente salvate il file.

Il file corrispondente lo trovate in:

/Users/emidiostani/.netbeans/6.1/config/Templates/Properties/User.properties

Ora non dovete fare altro che creare una classe Java come avete sempre fatto e vedete che la nota viene aggiunta in cima al file.

Riferimenti:

http://blogs.sun.com/geertjan/date/20071126

Raccogliere dati sul repository Subversion: WebSVN e StatSVN

Probabilmente in molti hanno provato a configurare Apache per poter vedere un repository di Subversion con una delle classiche configurazioni come la seguente che ho realizzato su di un server a disposizione:

<Location /svn/repos>
   DAV svn
   SVNPath /home/svn/repos
   AuthType Basic
   AuthName "Subversion Repository"
   AuthUserFIle /home/emidio/.htpasswd
   Require valid-user
</Location>

configurazione che va messo in /etc/apache2/mods-available/dav_svn.conf dove /home/svn/repos è il vero e proprio repository subversion mentre .htpasswd contiene il file utenti/password per l’autenticazione. Per maggiori informazioni leggete la pagina di manuale.

Cosi se poi andate su htttp://localhost/svn/repos potete scorrere il vostro repository usando il browser e conoscendo solo lo stato dell’ultima revisione.

Oggi vi presento 2 strumenti interessanti a chi ha un progetto condiviso con Subversion: WebSVN e StatSVN.

WebSVN è una applicazione PHP (richiede minimo PHP 4.3.0) rilasciata con licenza GPL che vi permette di monitorare, tramite pagine web la struttura del vostro repository Subversion (richiede minimo SVN 1.2.0).

In pratica potete vedere l’ultima revisione del progetto, autore e log message sul lato sinistro e sulla destra potete scorrere tra le cartelle e file del repository che potete monitorare tramite RSS feed.

Cartelle e file sono indicati dal loro numero di revisione; selezionando un file vedete la sua ultima revisione ma se cliccate su View Log ad esempio vedete la lista delle sue revisioni che potete vedere una per una (Details) o confrontare tramite una piacevole interfaccia grafica.

Eccovi un link dove viene spiegato in breve come installarlo su Linux (l’ho testato su Ubuntu 8.10). Per Subversion ho anche usato questo link. In pratica dovete copiarlo nella cartella /var/www servita da Apache e cambiare il file di configurazione puntando a subversion (/usr/bin) e alla cartella padre del repository di Subversion (nel mio caso avendo il repository in /home/svn/repos ho indicato il path /home/svn).

Per abilitare gli RSS feed dovete settare i permessi della cartella /var/www/websvn/cache a 777 (ho provato 700 e 770 ma mi dava problemi di permessi).

La cosa carina è che avete il syntax highlighting (l’ho provato su codice PHP, file CSS, file javascript, perl) che è basato di default su GeSHI che supporta molti linguaggi altrimenti potete usare Enscript 1.6 o superiore (insieme a Sed) che deve essere già installato sul sistema.

Ulteriori info le trovate in locale  su: http://localhost/websvn/doc/install.html

StatSVN è invece una applicazione Java (file jar compresso in un file zip di appena 2.4 mega) rilasciata con licenza LGPL che genera statistiche dettagliate sul repository subversion. Arrivato il 22 maggio scorso alla versione 0.5.0, StatSVN ha ora la possibilità di essere usato tramite Twitter.

La cosa interessante che ho notato nel manuale è che si può integrare con Bugzilla, Mantis e Trac.

Il sommario delle statistiche lo vedete dalla pagina principale index.html che vi mostra:

  • quando è stato generato il report
  • ultima revisione
  • su che periodo si basa
  • numero totale di file
  • numero totale di linee di codice
  • numero di sviluppatori
  • un collegamento a Twitter
  • un menu che mostra maggiori dettagli
  • il grafico sommario delle linee di codice
  • la tag cloud delle parole usate nei messaggi di log
  • la struttura gerarchica delle directory, dove per ognuna vedete il numero di file e le linee di codice contenuti.

Nota: I grafici sono realizzati tramite JFreeChart.

Nel menu dei dettagli vedete ad esempio, quante linee di codice ha scritto un particolare autore, il numero di commit per ora e giorno della settimana,i log dei commit, che tipi di file ci sono ordinati per loro numero (1o file php, 4 xml ecc.) e quante linee di codice in media ci sono per ogni tipo, lista dei file più grandi e più revisionati, tabella e grafico a torta delle dimensioni delle cartelle e tanto altro.

Per vedere una demo subito andate a questo link oppure potete vedere anche la demo su progetti come Ant, Apache Synapse, Apache Continuum, Ruby.

Non c’è in pratica installazione (ha bisogno almeno di SVN 1.3) dove lanciarlo nel seguente modo come indicato nel manuale:

svn co svn://server/repo/trunk/modulename
svn log -v –xml > logfile.log
java -jar /path/to/statsvn.jar /path/to/module/logfile.log /path/to/module

In pratica dovete fare un checkout del progetto, generare il file di log e sulla base del path indicato eseguire il file statsvn.jar.

Sarebbe bello però rendere automatica la procedura ed ecco che ho pensato a come integrarlo con Hudson e ho notato che qualcuno ci ha provato ma senza successo, io ho ripreso la sua configurazione e l’ho leggermente modificata.

Ho copiato prima di tutto il file statsvn.jar nella cartella lib di Apache Ant in modo che sia raggiungibile dalla variabile di ambiente ANT_HOME che punta alla directory di Ant.

Poi sono andato nel file build.xml della mia applicazione in Netbeans e ho notato che importa il file build-impl.xml che ha al suo interno una lunga serie di target. Tra le dipendenze del target default ho aggiunto statsvn-clean, statsvn e alla fine del file (prima della chiusura del tag </project>) ho aggiunto:

<taskdef name=”statsvn” classname=”net.sf.statsvn.ant.StatSvnTask”/>

<!– output directory for reports –>
<property name=”StatSVNReportDir” value=”statsvn”/>

<target name=”statsvn-clean” description=”resets to a clean state”>
<delete dir=”${StatSVNReportDir}” failonerror=”no”/>
</target>

<target name=”statsvn” description=”Does SVN repository statistics.”>
<echo message=”Metrics: running statsvn …”/>

<delete file=”${StatSVNReportDir}/svn-log.xml” />
<mkdir dir=”${StatSVNReportDir}” />

<exec executable=”svn” dir=”${src.dir}” output=”${StatSVNReportDir}/svn-log.xml” searchpath=”true” >
<arg line=”log –xml –verbose” />
</exec>

<statsvn
log=”${StatSVNReportDir}/svn-log.xml”
path=”..”
outputDir=”${StatSVNReportDir}/html” />

</target>

Ho poi fatto il commit di questo file sul repository SVN e così Hudson (che è impostato per fare il polling di Subversion) lo cattura e, poichè è impostato di fare il build periodicamente, mi genera anche la cartella statsvn (vedi proprietà StatSVNReportDir sopra) dell’ultimo build con tutte le descrizioni dettagliate. Come vedete come path gli ho indicato “..” per specificare la root del progetto in quanto non tutti i file del progetto si trovano nella cartella src come, ad esempio, le pagine jsp che normalmente le trovate nella cartella web.

A questo punto non mi resta che augurarvi buone statistiche !

Nota: ho usato Subversion 1.6.2, Hudson 1.296 e Ant 1.7.0

Sperimentando con Netbeans, Glassfish, Hudson e Subversion

Ho cominciato a scrivere qualche applicazione web con Netbeans 6.1 (penso di migrare presto (magari anche oggi) alla versione 6.5) e ho preso ad esempio il tutorial:

http://www.netbeans.org/kb/docs/web/quickstart-webapps.html

Il tutorial spiega come creare un paio di pagine Jsp facendo uso di una classe java usata come java bean, benchè dicono che richiede Netbeans 6.5 io ho usato tranquillamente Netbeans 6.1. Inoltre, durante il wizard, dovete specificare dove si trova Glassfish; ho preferito usare la mia istanza di Glassfish 2.1 scaricato a parte.

A parte ciò era mia intenzione di installare un server subversion e farne il polling tramite Hudson.

Ho trovato questo tutorial che spiega passo passo come prendere confidenza con Subversion; il tutorial suggerisce per Mac OS X di prendere Subversion da qui. Il pacchetto include Subversion 1.6.2 client e server (una volta installato potete provare i comandi svn –version e svnserve –version). Subversion mi si è installato in /opt/subversion/bin e non /usr/local/bin come descritto nella pagina di Collabnet; dovete quindi aggiungere il path /opt/subversion/bin nella variabile di ambiente PATH (che ho specificato nel file .bash_profile che si trova nella cartella utente).

Dopo aver giocato con il tutorial ho cercato subito di connettere Netbeans e Subversion e ho impostato in Preferences->Miscellaneous-> Versioning -> Subversion il path /opt/subversion/bin lasciando le altre impostazioni inalterate.

Inoltre ho poi cliccato con il tasto destro del mouse sulla cartella del progetto e sono nel menu contestuale sono andato in Versioning ->Import into Subversion Repository dove dovete specificare più che altro il path del repository che nel mio caso era:

file:///Users/emidiostani/SVNrep

(ho usato il repository creato con il tutorial su subversion)

Durante il wizard ho avuto un errore del tipo:

Expected FS format between ‘2’; found format ‘4’

che ho risolto facendo l’upgrade del plugin per subversion dalla versione 1.3 alla 1.3.1, difatti se andate nel repository (nel mio caso la cartella SVNrep) c’è il file /db/format che dice la versione del db interna è 4, in pratica non c’è accordo da tra client in netbeans e il server (noto che in Netbeans 6.5 potrebbe esserci lo stesso problema, vedere qui).

Sono poi andato su Hudson (versione 1.296) che vuole l’URL del repository e allora nella cartella di subversion ho lanciato il comando:

svnserve -d

che esegue il server che rimane in ascolto di default sulla porta 3690 (lo potete vedere da shell con il comando netstat -ant -p tcp). Ho trovato una breve descrizione di svnserve qui.

Cosi poi su Hudson ho inserito l’URL:

svn://localhost/Users/emidiostani/SVNrep

quando poi sono andato a specificare, nel form Build, il target file da compilare ho messo:

./HelloWeb/build.xml

che il target file che Netbeans mi aveva creato al momento del progetto.

Succede però che quando eseguo il build su Hudson esso mi genera un errore del tipo:

BUILD FAILED
/Users/emidiostani/.hudson/jobs/Test/workspace/SVNrep/HelloWeb/nbproject/build-impl.xml:188: The Java EE server classpath is not correctly set up. Your active server type is J2EE.
Either open the project in the IDE and assign the server or setup the server classpath manually.
For example like this:
ant -Duser.properties.file=<path_to_property_file> (where you put the property “j2ee.platform.classpath” in a .properties file)
or ant -Dj2ee.platform.classpath=<server_classpath> (where no properties file is used)

Total time: 0 seconds
Finished: FAILURE

questo accade perchè nel file HelloWeb/nbproject/build-impl.xml alla riga 188 esiste la riga:

<fail unless=”j2ee.platform.classpath”>

ecc ecc.

in pratica non trova la directory delle librerie di glassfish, questo l’ho scoperto semplicemente aggiungendo:

<echo>using ${j2ee.platform.classpath}</echo>

subito dopo quella riga e compilando direttamente da Netbeans.

Ovviamente Hudson non può sapere questa informazione che arriva direttamente dalle impostazioni di Netbeans e perciò per arrangiare ho messo nella casella Properties la voce:

j2ee.platform.classpath=/Users/emidiostani/Desktop/glassfish/lib/

e così sono riuscito a compilare.

In pratica leggendo poi in questo post, si capisce che la variable j2ee.platform.classpath è settata in HelloWeb/nbproject/private/private.properties file che non viene caricato nel repository (potete notarlo nel workspace di Hudson) e di conseguenza Hudson non la trova. L’autore del post suggerisce di settare la variabile nel file HelloWeb/nbproject/project.properties invece di settarla in Hudson perchè se pensate bene è una variabile statica che dovrebbe essere inclusa in diversi progetti in hudson e sarebbe giusto fissarla a monte.

Comunque come ho tempo rifaccio il tutto su Netbeans 6.5.

Buona giornata !