Nel precedente articolo, vi ho accennato all’uso di Eclipse, Tomcat e Axis2 per la creazione di web services.

Vi sarete chiesti: come faccio a sapere che il tutto stia funzionando passo per passo oltre a vedere l’output da console ?

Potete usare 2 modi:

1) vedere i messaggi scambiati tra client e server

2) usare il debug remoto

Se non usate Axis2, ma un semplice client server che comunicano tramite una porta, puo’ esservi utile TCPMon una applicazione java che si esegue da un unico jar file a cui dovete configurare come porta locale una porta che il vostro client deve chiamare e la server port la porta del vero server. In pratica esso funziona come proxy permettendovi di vedere i messaggi scambiati.

Se usate Axis2 potete usare il SOAPMonitor che, come TCPMon, è una sorta di proxy che si infrappone nella comunicazione. Non sono riuscito a farlo funzionare su Axis2 1.4, in rete ho trovato un tipo che lo ha fatto funzionare ma non voglio perderci tempo, mentre ci sono riuscito su Axis2 1.3 semplicemente estraendo dal file soapmonitor-1.3.jar (presente in Axis2) le classi in esso contenute e copiandole nella root directory di Axis2 (stiamo parlando della directory di Axis2 che sta dentro Tomcat).

Alternativamente al SOAPMonitor c’è il tracer di WSO2 Web Services Application Server o WSAS. Questo application server è formato da Tomcat e Axis più la serie di moduli che si appoggiano ad Axis come Apache Rampart per quanto riguarda la sicurezza (WS-Security) o Sandesha per quanto riguarda l’affidabilità (WS-ReliableMessaging). Nell’interfaccia web di Axis2 avete sicuramente notato la sezione dedicata ai moduli che possono essere agganciati a tutti i web services o solo ad alcuni. Ebbene WSAS permette di averli già tutti installati (vi risparmia la fatica) offrendo dalla sua interfaccia web una serie di tool tra cui il tracer.

Per quanto riguarda il tracer ho trovato WSAS 2.1 più stabile di WSAS 2.2 e 2.3 (ultima versione al momento in cui scrivo). Quello di 2.2 mi geneva una eccezione mentre leggevo un messaggio quello di 2.3 funziona ma in WSAS esiste uno strumento che permette di provare un web service da interfaccia web (una volta selezionato il web service cliccate su Try it) che mi ha funzionato meglio su 2.1 che su 2.3. Poi ovviamente fate voi.

2) Come per le applicazioni stand alone potete inserire dei breakpoint nel codice e fare il debug potete fare lo stesso anche per i web services a patto che l’application server ve lo consente (Tomcat di sicuro) e che dal vostro IDE (di sicuro Eclipse) possiate lanciare l’applicazione in debug mode. In sostanza IDE e application server si accordano su una porta per il debug; Il tutto è dovuto alla Java Platform Debugger Architecture. Cercate “eclipse remote debug” in Google e troverete esempi come:

http://www.eclipsezone.com/eclipse/forums/t53459.html

o questo:

http://www.onjava.com/pub/a/onjava/2005/08/31/eclipse-jboss-remote-debug.html?page=1

Il 16 luglio l’Univesità di Pavia, in occasione delle “Porte Aperte”, si propone di divulgare  il software libero a scopo didattico dove, in un ciclo di 3 incontri verrà distribuito e spiegato l’uso del sistema operativo Fedora 9.

Per ulteriori info:

http://www-1.unipv.it/webaule/porteAperte2008/index.html

Per un progetto in azienda sto lavorando con i web services, usiamo pero’ vecchie versioni di eclipse e axis2 poichè il progetto è iniziato con quelle versioni e non si può cambiare strumento durante lo sviluppo, come è giusto che sia. Per i fatti miei però ho sperimentato la generazione di web services dapprima con Netbeans 6.1 e poi con Eclipse 3.4.

Introduzione

Come da titolo dovete scaricare Eclipse, Tomcat e Axis2. Io ho scaricato Eclipse 3.4 per Java EE, Tomcat Core e Axis2 il file war ma anche la standard binary distributition perchè essa contiene dei comandi che il war file non ha.

Tomcat è un application server e dovrà lanciare Axis2 che funge da contenitore per i vostri web services e vi permette anche di gestirli. Con Eclipse dovrete creare le classi java per il client e il server.

Iniziamo

Una volta estratta la standard binary distribution, create la variabile di ambiente AXIS2_HOME in modo che punti ad essa e poi copiate il file war nella cartella /webapps di Tomcat. Ora, se volete, potete far partire tomcat lanciandolo dalla sua cartella /bin e con il vostro browser andare all’url:

http://localhost:8080

8080 è in genere la porta su cui Tomcat gira. Dovreste vedere la pagina di Tomcat, se cliccate a sinistra su Tomcat manager vedete la lista di applicazioni tra cui c’è Axis2. Cliccateci sopra e vi compare la pagina di Axis2. Come primo link c’è “Services” che indica gli attuali web services che stanno girando tra cui ci sarà anche il nostro.

Come vi ho già detto nella standard binary distribution ci sono dei comandi che nel war non sono presenti e sono java2wsdl e wsdl2java (vedere qui per tutti i parametri)

Se siete nuovi nel mondo dei web services dovete sapere che i file wsdl sono dei file xml che descrivono i web services percio’ prima di proseguire vi consiglio di studiarvi XML, i file xml schema e i file wsdl in generale (potete dare una occhiata al sito w3schools). Occorre saperlo perchè grazie al comando wsdl2java potete creare, a partire dal file wsdl, ciò che sta sotto la comunicazione tra client e webservice ovvero stub e skeleton.

Stub e skeleton sono delle classi java che fungono da proxy ovvero il vostro client chiamerà lo stub per la comunicazione mentre il webservice userà lo skeleton per ricevere, ed eventualmente trasmettere, i dati.

In un precedente articolo ho spiegato come potete validare i vostri file wsdl in modo da diminuire i rischi di interoperabilità, pensate ad esempio ad un client (stub) realizzato in java ed un web service (skeleton) realizzato sotto .NET.

Il comando java2wsdl potete immaginare cosa fa.

Questi comandi, come descritto nella reference di Axis2 sono molto semplici da usare ma una interfaccia grafica non dispiace.

Il servizio andrà poi impacchettato in un archivio axis (file aar) e deployato  (in altre parole copiato e spacchettato, lasciatemi passare il termine) nella cartella di Axis2 sotto Tomcat.

Ho dapprima provato il plugin di Netbeans ma personalmente credo che andrebbe migliorato perchè è possibile selezionare poche cose e, inoltre, obbliga alla all’inserimento di parametri (-g) a linea di comando (da dentro l’interfaccia!) per la generazione del client, in quanto, in automatico, lui crea lo skeleton e l’unico modo per creare lo stub è aggiungere il parametro; per il resto il plugin si comporta bene. Il tutorial che ho seguito è questo. Tuttavia ho poi proseguito per Eclipse anche se poi ho scoperto che il plugin è buggato ma ho trovato rimedio.

I plugin di Axis2 sono a mio avviso più completi e si scaricano dal sito di Axis2 e precisamente sono il Service Archive Wizard 1.4 e il Code Generator Wizard 1.4 che come vedete nella tabella richiedono Axis 1.4.

Il primo serve per creare l’archivio axis da copiare in Tomcat il secondo come interfaccia per i comandi java2wsdl e wsdl2java.

Non dovete fare altro che scaricare i plugin ed estrarli nella cartella plugins di Eclipse e correggere qualche bug .

In pratica nella cartella del Code Generator c’è un file che si chiama plugin.xml, in questo file sono descritte le librerie di cui il plugin si serve, tra queste notate che c’è l’archivio jar stax-api-1.0.1.jar ma questo non si trova nella cartella lib del plugin e dovete scaricarlo dalla rete (vedete qui). C’è poi un pacchetto che manca proprio e che è backport-util-concurrent-3.1.jar (lo trovate nella cartella /lib di Axis2) che dovete aggiungere nella cartella lib e nel file plugin.xml (in pratica tutto cio’ serve per risolvere l’eccezione java.lang.reflect.invocationTargetException che si manifesta all’ultimo passaggio del wizard).

Nel caso in futuro avete degli errori lanciate Eclipse in debug mode da console in questa maniera:

eclipse -clean -debug

L’opzione debug vi permette di vedere eventuali errori da console, clean pulisce una cache che Eclipse usa quando crea i vostri progetti (per altri parametri vedere qui). Se ancora avete problemi come ultima speranza rimuovete il plugin che vi da fastidio dalla cartella nascosta .metadata/.plugins che si trova nel vostro workspace.

Non fate partire ancora Eclipse perchè voglio segnalarvi un altro plugin che vi permette di lanciare/fermare Tomcat da Eclipse questo plugin lo trovate qui ed è semplice da installare come spiega il sito (in pratica va poi messo nella cartella dropins di Eclipse e occorre configurare il plugin indicando il path di tomcat).

Ok ora siete pronti per lanciare Eclipse, dovrete creare un progetto java e seguire questa guida suddivisa in 2 parti che vi spiega per filo e per segno tutto.

Durante la guida vi ritrovete a creare il codice java per lo stub dal file wsdl, il wizard vi chiede l’inclusione delle librerie del codegen ma questa non va e perciò dovrete farlo a mano agggiungendole direttamente nel vostro Build Path prendendole dalla cartella lib del plugin Codegen. Attenzione potrebbe essere un problema del Mac, ho notato che in debug mode, al momento della creazione del codice eclipse pensa di trovare il plugin nella cartella /eclipse/Contents/MacOS/plugins e non, come dovrebbe essere, in /eclipse/plugins, perciò se siete sotto Mac copiate i 2 plugin anche in quella cartella (da creare) e cosi al momento della generazione pesca correttemente i jar file della cartella lib.

Se non vedete il codige generato provate a fare un refresh del progetto. Volevo farvi notare che quando il wsdl viene caricato il plugin carica anche gli XML schema collegati (se ve ne sono) e quindi fa un controllo sulla validità, potete notare il caricamento se usate Eclipse in debug mode; tra l’altro una volta che avete creato il file wsdl potete validarlo selezionandolo e cliccando sulla voce di validazione dal menu contestuale aperto con il tasto destro del mouse.

Quando vi viene chiesto di compilare fatelo usando il file build.xml (tasto destro ed “esegui” dal menu contestuale) che viene automaticamente generato e conosce tutte le dipendenze.

Quando eseguirete il client avrete una eccezione riguardo il file jar woden API che è mancante questo perchè con Axis 2 1.4 questo package è richiesto; prendetelo dalla cartella lib di Axis2 e aggiungetelo al vostro build path. Ho semplicemente aggiunto solo il jar delle woden API.

Non vi preoccupate del warning su log4j è perchè non trova il suo file di configurazione.

Quando andate a generare lo skeleton che dovete riempire fate caso al fatto che i parametri in ingresso del metodo terminano con un numero.

Notate anche che quando generate lo stub questo ha come sottoclassi le richieste e le risposte mentre quando generate lo skeleton queste sono messe nei rispettivi file.

Nella parte 2 del tutorial vi verrà chiesto di usare il file services.xml che è stato generato nella cartella resources, ebbene in teoria dovreste poterlo selezionare in pratica dovrete inserire il suo path a mano.

Tra l’altro vi faccio notare che, sempre nella parte 2, il file wsdl viene generato nuovamente nella cartella resources, il file è pressocchè identico a quello di partenza anche se è questo che viene usato per la generazione del servizio con il Service Archiver.

Nella parte 2 vi viene chiesto di inserire la parte del client ebbene inserite il codice usato nella parte 1 e non quello proposto.

Se siete arrivati fino alla fine del tutorial complimenti! La strada per connettere e dare più funzionalità ai web services è lunga ma ora avete la basi per poterne creare.

Aggiornamento 1

Se avete avuto occasione di creare da zero wsdl, avete visto la comoda possibilità di includere XML schema dentro in modo da separare la descrizione del servizio dai tipi usati nei messaggi.

In questo ambito ho scoperto che il plugin Service Archiver ha un bug, semplicemente non include l’XML schema usato dal file WSDL dentro l’archivio aar creato e dovete purtroppo farlo a mano, a meno che c’è qualcuno che vuole modificare il codice (dovrebbe essere semplice ma non ho voglia, considerate che c’è la libreria WSDL4J che puo’ aiutarvi). Per modificarlo spacchettare il file aar (una volta rinominato in zip), aggiungete il file e rimpacchettate.

Alla prossima

P.S. Ho usato la java virtual machine 1.5.0_13

Il 15 luglio, sempre sul versante ligure, verrà organizzato un incontro con tema Google Web Toolkit da parte del JUG di Genova.

Se siete in cerca di una tecnologia ajax e vi ritrovate da quelle parti, magari per fare una passeggiate sul litorale ligure, l’evento può fare per voi, l’incontro è di pomeriggio perciò per la passeggiata prendetevela comoda.

La partecipazione è gratuita ma si richiede una registrazione on line:

http://juggenova.net/

Se vi ritrovate dalle parti di Savona, dovete sapere che il LUG di Finale Ligure (borgo) sta organizzando un ciclo di incontri già iniziato il 23 giugno.

Il prossimo è il 7 luglio dove verrà spiegato Gimp e quelli dopo sono ancora più interessanti soprattutto per chi è alle prime armi.

Vi ricordo che la partecipazione è gratuita.

Riferimenti:

Link al Lug di Finale Ligure

Lavorando con i web services sorge il problema dell’interoperabilità, magari qualcuno si chiede “ma come è possibile? I web services garantiscono l’interoperabilità grazie al fatto che espongono servizi sulla rete e poi ho li ho anche validati…”. Ebbene si questo è in parte vero in parte perchè spesse volte si riferiscono a xml schema e quindi strumenti (come Eclipse) ne garantiscono la validità se questi schema vengono rispettati.

Ma ciò non basta. Non basta perchè il modo in cui sono scritti influenza il modo in cui le classi java o C# sono generate e ne sto qui a parlare proprio perchè in azienda abbiamo avuto questo problema. Un’altra azienda ha scritto dei file wsdl da cui ha generato classi java (tramite lo strumento di Axis2 wsdl2java) e su cui poi ha lavorato per un progetto. Questo progetto dovrà poi essere realizzato in C# con piattaforma .NET.

Fatto sta che gli strumenti che generano le classi C# non riescono perchè non trovano valido il file wsdl utilizzato!!! Vi domanderete “come faccio a sapere quali sono gli accorgimenti che devo prendere?”

Attualmente la bibbia di riferimento è il Basic Profile, una sorta di studio che ha portato a definire delle regole per ridurre i rischi derivanti dall’interoperabilità. Il BP è stato realizzato dal Web Service Organisation WS-I una specie di consorzio guidato da SAP, Fujitsu, Microsoft, HP, Sun, IBM, Intel, Oracle ecc

In questo BP si fa cenno a diverse tecnologie per usate per i web services SOAP, WSDL UDDI, XML schema, HTTP e HTTPS vi invito quindi a dare uno sguardo.

Al di là della sola lettura occorrono strumenti di verifica e che ho trovato grazie a questo articolo. In pratica il WS-I ha rilasciato uno strumento chiamato Interoperability Testing Tools (su un accenno a come si usa vedere qui) che è stato poi integrato in altri strumenti come soapUI un software in parte rilasciato open source con licenza GNU Library o Lesser General Public License (LGPL) in parte, la versione Pro, in via commerciale. soapUI è stato realizzato come applicazione stand-alone ma anche come plugin per Eclipse, Netbeans, IntelliJ e Maven.

Esistono altri strumenti che troverete nell’articolo che vi ho indicato e che da oggi ho cominciato a valutare.

Benvenuti nel meraviglioso mondo dell’interoperabilità

Mentre oggi ero intento a generare un po’ di web services tramite axis2 il mio capo mi chiede di fare un lavoretto per conto di altre persone in azienda.

In pratica chiedono di modificare all’incirca 100.000 file di testo in formato XML, di 2kb, modificando il testo all’interno di un tag. La modifica è uguale per tutti: il testo da modificare in pratica contiene un path ad un file pdf e si  tratta aggiungere alla fine del path l’estensione “.pdf”.

Mi sono detto, siccome sto studiando Ant, perchè non farlo con questo ?

La cosa buona di Ant è che si puo’ installare ovunque ci sia una java virtual machine, fino ad ora avevo usato i miei script bash ma il mio capo mi disse sarebbe bello poterli far girare su Windows cosi’ ho preso a studiarmi Ant che non credo (fino ad ora) sia potente come la bash ma scopro di giorno in giorno le sue potenzialità. Qualcuno dirà che anche il perl e il python possono essere usati ma ho preferito questo.

In realtà Ant è una applicazione java e i suoi script sono file xml. I tag di questi file corrispondono a relative classi java permettendo quindi la loro estensione.

Ant può copiare e spostare file e directory, creare jar e war file per il deploy, calcolare l’md5 dei file, agire su variabili da usare come condizioni, collegarsi ad un CVS, creare test con Junit e tra le altre cose lavorare con le espressioni regolari.

Se vi serve una introduzione ad Ant, che vi collega al mio precedente articolo sull’integrazione continua, la redazione di Mokabyte ne scrisse una interessante:  eccovela !

Una volta installato (estratto) Ant ho configurato le variabili di ambiente ANT_HOME che punta alla cartella estratta e PATH che punta alla sottocartella bin.

Ho poi creato il file “build.xml” e l’ho messo insieme a file da modificare; il fatto di metterlo nella stessa cartella non è strettamente necessario perchè poi gli do la cartella di lavoro come parametro.

Ed eccovi il file:

<?xml version="1.0" encoding="UTF-8"?>
<project name="program" default="convert" basedir=".">
<property name="folder" value="." />
<property name="backup_folder" value="backup" />
<property name="file_extension" value="inf" />
<property name="tag" value="PrintFileName" />
<property name="extension" value="pdf" />

<target name="backup" description="backup folder">
<mkdir dir="${folder}/${backup_folder}" />
<copy todir="${folder}/${backup_folder}" >
<fileset file="${folder}"/**.*${file_extension}" />
</copy>
</target>

<target name="del_extension">
<replaceregexp
  match="<${tag}>(.*).${extension}<\/${tag}>"
  replace="<${tag}>\1<\/${tag}>">
<fileset dir="${folder}" includes="**/*.${file_extension}" />
</replaceregexp>
</target>

<target name="add_extension">
<replaceregexp
  match="<${tag}>[^(\.${extension})]<\/${tag}>"
  replace="<${tag}>\1.${extension}<\/${tag}>">
<fileset dir="${folder}" includes="**/*.${file_extension}" />
</replaceregexp>
</target>

<target name="convert" description="open files and add an extension to the text inside the selected tag">
<antcall target="backup" />
<antcall target="add_extension" />
</target>

</project>

Intestazione XML a parte, nella seconda riga dichiaro che il target (funzione o metodo) da richiamare di default è convert. All’interno di questo target richiamo dapprima il target backup che realizza il backup della directory di lavoro e poi richiamo add_extension per modificare i file xml.

I parametri di default quali la cartella di lavoro (folder), la cartella di backup (backup_folder), l’estensione dei file che vado a modificare (file_extension), il tag xml che seleziono (tag) e l’estensione che aggiungo nel path (extension) sono definiti all’inizio del file e possono anche essere passati come parametro ad Ant.

Ad esempio se do:

ant -Dfolder=./test

Indico che la cartella dei file da modificare è la sottodirectory test, attenzione che se nel path ci sono degli spazi dovete usare le virgolette ” ” prima e dopo il path.

Il target backup crea quindi una cartella (mkdir) di backup dentro alla cartella di lavoro e copia in essa (copy) i file dalla cartella di lavoro con l’estensione che ho indicato (fileset). Se non volete fare il backup potete semplicemente rimuovere il suo richiamo nel target convert.

Andiamo alla parte delicata, come avete notato il target del_extension non viene richiamato, me lo sono lasciato per convienenza e vi permette di capire più facilmente il target add_extension.

Con il target del_extension si vuole selezionare tutti i path con il tag selezionato che già contengono la stringa “.pdf” e rimuoverla. Per fare ciò usiamo il task replaceregexp che ha 2 attributi: match e replace.

Con l’attributo match selezionamo il tag XML, di default PrintFileName, che contiene la stringa mentre con il tag replace sostituiamo la stringa trovata. I caratteri < e > mi servono per sostituire < e > in quanto non vengono accettati direttamente, poi vedete la variabile ${tag} che viene aperta e chiusa (usando \/ in quanto il simbolo / è particolare) e all’interno l’espressione (.*) che indica tutti i caratteri con a seguire l’estensione .${extension}.

Quello che vogliamo fare è sostituire tutti i caratteri trovati nel mezzo togliendo l’estensione, il risultato della stringa trovata in match con i caratteri (.*) è indicata con \1.

Applico infine questa trasformazione all’insieme di file tramite il task fileset.

Il target add_extension dovrebbe funzionare al contrario se non che può capitare che alcuni path finiscano già per “.pdf” e quindi corriamo il rischio di aggiungerli nuovamente perciò nel mezzo è stato aggiunta l’espressione [^(\.${extension})] che indica di escludere tali path.

Semplice no ?

Ora non sono un esperto di espressioni regolari, me le sono giuste viste un pò, ma la cosa mi ha fatto apprezzare di più Ant.

Sono sempre alla ricerca di nuovi software liberi possibilmente multipiattaforma.

Di client torrent ce ne sono a bizzeffe ed io fino ad ora mi sono accontentato di usare Transmission sotto Ubuntu e Mac OS X e mi va bene cosi’ in quanto è leggero e posso anche impostare upload a 0 (la mia connessione è a banda limitata sul totale in ingresso e uscita).

Oggi ha destato mio interesse Torrentflux, un client web da poco giunto alla versione 2.4, scritto in PHP e rilasciato con licenza GPL. L’installazione su Xampp si rilevata semplice, ho estratto il file compresso (1.5 MB) nella cartella htdocs, creato il database torrentflux da PhpMyAdmin e caricato il file sql che si trova all’interno della cartella di Torrentflux.

All’avvio chiede username e password di amministratore e poi si presenta una interfaccia web, semplice e intuitiva, che vi chiede per prima cosa che la cartella di download sia settata con permessi 777.

La cosa interessante è che è basata su utenti che dispongono di una propria cartella, si può dire quindi che se messo su pc che fa da server può riverlarsi utile.

Potete poi fare ricerche su server torrent, caricare un torrent da url e da disco e monitorare lo stato dei download con una barra di progressione usata anche per mostrare lo spazio del disco rimanente (non si sa mai che state scaricando troppo e non vi accorgete che lo spazio sta per finire )

Per ulteriori dettagli vi rimando alla pagina del wiki di Ubuntu-it che è ben dettagliata:

http://wiki.ubuntu-it.org/InternetRete/Condivisione/TorrentFlux

Buon download !

Attualmente sto dietro ad un progetto realizzato in java per creare una infrastruttura di web services che si scambiano messaggi e, nel campo del software libero, in azienda usiamo svariati software:

• WSO2 esb come bus per connettere i web services fra di loro
• Intalio per la generazione di workflow che viene trasformato in web services
• Ant per la generazione di script per automatizzare procedure di compilazione e deploy
• Tomcat & Axis2 per il deploy dei webservices e anche per la generazione automatica degli stessi a partire da file wsdl
• Squid come url rewriter
• Eclipse per lo sviluppo
• SubVersion come CVS e Subclipse come client installato su Eclipse
• Openlaszlo per un paio di applicazioni che fanno da viewer
• Axiom/Stax e Xmlbeans come librerie per il parsing di file XML e la generazione di file java da xml schema
• ecc.

L’ultimo di questi è Apache Continuum che, arrivato alla versione 1.1, è uno dei tanti prodotti della Apache Software Foundation rilasciato con licenza Apache Licence 2.0

Continuum in sostanza lo usiamo per prendere i file immagazzinati del repository di SubVersion e fargli fare la compilazione dell’intero progetto alle 23.00 di ogni notte. La gestione di questa attività avviene tramite una semplice interfaccia web e inoltre il risultato della compilazione puo’ essere mandato per email agli sviluppatori (nota noi non l’abbiamo fatto in quanto siamo in pochi pero’ ovviamente è una cosa utile).

Via interfaccia web gli forniamo quindi il link del repository di SubVersion, il file ant che usa per la compilazione con i vari target e il tempo di schedulazione come in cron. La configurazione del server di posta va fatta editando il file apposito.

Continuum si puo’ installare in 2 principali modi: come standalone application o come applicazione che necessita un application server come Tomcat ad esempio. Noi l’abbiamo installato come standalone  perchè è messo su un server (per mia sfortuna Windows 2003 Server) e non volevamo installare un application server e abbiamo seguito questa guida (dove pero’ non abbiamo patchato Ant).

Per avere idea di come funziona vi consiglio di vedere la demo, un articolo collegato e un vecchio articolo che ho trovato in rete.

Alternativa a Continuum puo’ essere Cruise Control ed altri pochi software che vedete qui.

Nota: nell’interfaccia web Continuum chiede di mettere il path per la cartella di lavoro e destinazione, cercate di mettere un path corto perchè su Windows si incazza.

Buona integrazione!

Pronti per la prossima conferenza di ben 3 giorni sul Software Libero ?

Se la risposta è si sappiate che l’Univesità di Trento, precisamente la Facoltà di Economia, ospiterà la conferenza che avrà luogo dal 16 al 18 Maggio (per come arrivare vedete qui).

Sponsorizzata anche da SUN e IBM, la conferenza vedrà diversi partecipanti attivi nel panorama del software libero come la Assoli, i comuni di Trento e Bolzano, il Centros, Wikimedia Italia, Cristian Biasco autore del video blog sulla proprietà intellettuale ed anche l’IDABC, che è la sezione della Commissione Europea coinvolta nella realizzazione di un Osservatorio Open Source.

Le tematiche quindi spazieranno dalla proprietà intellettuale del cittadino all’interesse delle scuole e del comuni fino al Commissione Europea passando per il trashware.

Partecipate numerosi e siate attivi! Mi raccomando pero’ registratevi prima !