Qualcuno di voi si è mai trovato nella necessità di utilizzare nello stesso progetto Castle, NHibernate, Fluent NHibernate, Rhino tools, MVCContrib, ecc.?
Chiunque (e credo siano molti) si sia mai trovato in una situazione del genere sa bene a cosa il titolo del post si riferisce.
Tutti questi raffinati e fantastici strumenti hanno una serie di interdipendenze tali da rendere veramente difficile e tedioso l'aggiornarmento dei binari ad una nuova versione quando si ha la necessità di lavorare con l'intero stack di framework ALT.NET in un unico progetto.
L'obiettivo di Horn è di rendere estremamente semplici le operazioni di scaricamento e build dei framework open source di cui abbiamo bisogno nel nostro progetto. Si, ma semplici quanto?
Semplici quanto aprire la command line e digitare il comando seguente:
horn -install:nhibernate
questo(apparentemente) innoquo comando scatena una serie di operazioni tali che alla fine del processo ci si ritrova con una cartella da qualche parte con la build più recente (buildata dal trunk) di NHibernate completa anche delle librerie interdipendenti (anch'esse buildate dal proprio trunk).
Potrò, a questo punto, prendere i binari e copiarli nel mio progetto sicuro di non avere conflitti di versione tra le varie dipendenze.
Ma come funziona questa magia?
Horn introduce il concetto di build descriptor che altro non è che un file DSL scritto in boo che descrive da dove un determinato pacchetto deve essere scaricato (sono supportati svn e git), come il pacchetto deve essere buildato e quali sono le sue dipendenze.
Le dipendenze descritte puntano a loro volta al proprio build descriptor e possono quindi essere scaricate e buildate a loro volta.
In questo modo è possibile ottenere la build dell'intero albero di dipendenze del pacchetto desiderato.
Horn, di default, ha al suo interno una cartella package_tree che contiene i build descriptor della maggior parte (se non di tutti) dei framework e delle librerie più diffuse nella comunità .net. Ma è possibile costruire i propri build descriptor in maniera abbastanza semplice o contribuire al progetto inviando i build descriptor di librerie non ancora presenti nel package_tree.
Come ottenere Horn?
Horn è hostato su google code qui: http://code.google.com/p/hornget/
E' possibile scaricare Horn con svn o TortoiseSVN da qui: http://hornget.googlecode.com/svn/trunk/
Una volta ottenuto il sorgente è possibile buildare horn in maniera molto semplice lanciando il comando hornbuild.bat nella cartella src.
Completato il build sarà possibile lanciare horn dalla cartella:
src\build\net-3.5\debug
e iniziare finalmente a buildare i nostri framework preferiti!
Horn è un progetto iniziato dal gruppo Scotland ALT.Net. Il progetto è tutt'altro che maturo (credo non sia ancora entrato nella sua fase beta) e la direzione di sviluppo futura è ancora incerta. Da questo post del suo autore sembra (speriamo) che horn sia destinato a diventare un bellissimo sito web in cui ogni build descriptor del package_tree diventa una pagina web dalla quale è possibile scaricare uno zip con i binari dell'ultima build disponibile. Certo, sarebbe un bel boost per la nostra produttività…
L'autore, nel suo ultimo post datato 17 Settembre 2009 chiede aiuto alla community per la manutenzione e lo sviluppo del progetto, lamentando la recente tendenza di molti project leader di cambiare scm passando da svn a git o altro. Infatti, ad oggi, molti build descriptor di horn non sono aggiornati ai recenti cambiamenti di scm, rendendo di fatto inutilizzabili gli stessi (per esempio rhino, mvccontrib, sharparchitecture passati di recente su github.com).
Vogliamo contribuire allo sviluppo di questo meraviglioso progetto?
Qualche link sparso sull'argomento:
http://jasondentler.com/blog/2009/08/first-impression-horn/
http://thesoftwaresimpleton.blogspot.com/2009/07/breaching-castle-walls.html
http://thesoftwaresimpleton.blogspot.com/2009/04/horn-package-manager-introduction.html
Technorati Tags:
horn,
alt.net