Horn web is alive

The hornget website is a tangible landmark in horn’s journey from fun project to something of actual potential and use. It has been met with a predictable, muted response for something I genuinely believed was lacking in the .NET space. Horn is in OSS terms, very much an itch that needed scratching. One only has to look at the figures at the end of the post and the lack of publicity surrounding what could and should be a worthwhile community initiative for .NET OSS. It is easy for me to overstate the need for horn as I have been its most vigorous and active member since its inception. We now have a windows service that not only builds many of the favourite .NET OSS offerings but also sets out to resolve the dependency maze that is so intricately mapped out by the various rogue library versions that are now interspersed among the many lib folders of .NET OSS.

We have provided this and a DSL dialect for specifying the build and dependency instructions. As is usual with defined and set goals, we have over reached our initial expectations. This is very much a time to stop and review where we are and why this does not seem to be an interesting subject for .NET. I have been on a ruby on rails course this week and the use of ruby gems has obviously had a resonance with me.

The jury is very much out on whether this was a cause worth championing. I cannot justify my time on this project and I hoped this would be my way of repaying the massive debt to OSS. I am not even sure I learnt anything during the process apart from getting contributors to submit code to your OSS project is damn hard.

I will leave you with the horn scores on the doors via google analytics.

Dare to Question TDD?

I decided to write a quick follow up to my post yesterday. I made the following comment on this blog post:

TDD is a flawed paradigm by the very nature of having to write more lines of test code than production code. It has undoubted good side affects like higher quality code but nobody ever wants to discuss the flawed nature. Anybody who dares challenge it is slated as unprofessional:

Typically we get the same old cries of either being unprofessional or as is in this case is of Thomas Eyde we get the predictable cry of “You aren’t doing TDD” obviously. He posted the following quote:

You aren't doing TDD, obviously, because you don't want to use flawed methods. So how do you create your quality code? How do you verify your code does exactly what you intended it to do? How do you avoid to write code you don't need? How do you avoid to break working code when you apply your changes?

It is tedious for me to try and prove whether or not I do TDD, I can point to the horn tests as examples of the tests I have written. Anyway to get into such a debate is boring. For the record, I never once said you should not do it.

My question to the few people out there who may read this blog is a very simple one...

Why the hell can we not question TDD’s worth? Every time someone dares to question the flaws, they get slated as unprofessional.

The very fact that we end up writing more test code than production code makes me feel uneasy about the whole concept. TDD takes a very long time to get up to speed if you have no mentoring to accelerate the learning. The whole concept just seems loose with no clearly defined boundaries to help reign you into to a tighter feedback loop. For me, it took a while for the penny to drop with respect to how important it is to write a clearly defined failing test. I must stress clearly defined and not just a failing test.

TDD is flawed and instead of getting hot under the collar every time somebody dares to question it, we should be thinking of ways to improve the very loose and unguaranteed way the paradigm works. Of course I could just be very slow.

Or are we saying that we are totally happy with the experience and we will just leave it at that..................?

Holier Than Thou

I have to say I have enjoyed the duct tape furore thus far. The rumpus has succeeded in bringing a number of annoyances to the surface for me that have been bubbling like a geyser for some time.

Scott Reynolds reaction is the norm for the reaction of what I will now deem the guilty and both this post and this post are better articulated answers to the haughty and ill versed reaction of Mr.Reynolds.

What this whole duct tape debate has said to me is that as developers we are more concerned with the internal structure of our code than the external behaviour of the products or services we produce.

When do you ever see a developer blog about usability issues of a UI app which let us face it is what a lot of us are working on?

Usability is one of the main reasons for the failure of a UI application. We really need to grasp this concept while more and more development is outsourced.

I have had the misfortune to work on a project with a very well versed project lead whom in his wisdom had a dozen user stories and even a bounded context before we had a single web page when we were working on.......wait for it..............a web application. I fear this sad tale is not unique. You know who are and you should not be let loose on making the coffee never mind producing a working application within a decent timescale.

The echo chamber is quick to insult a code base they have never seen like stackoverflow but they cannot congratulate what is a well performing high traffic website. They have no interest in the external behviour but have perceived a big ball of mud for a codebase they have not laid a single eyeball on.

People seem very quick to blogboast about how they have adopted kanban, scrum, git or whatever the hell is du jour but all this is inward facing and does nothing for the saleability of the product.

TDD is a flawed paradigm by the very nature of having to write more lines of test code than production code. It has undoubted good side affects like higher quality code but nobody ever wants to discuss the flawed nature. Anybody who dares challenge TDD or some of the other craftsman attributed methodologies is slated as unprofessional. As an aside the term craftsman connected to software development makes me want to vomit. I use TDD to drive out the design of my code but have more or less abandoned integration tests as brittle and a waste of time. I use TDD because at this minute in time it is the best way for me to focus my mind in delivering small units of functionality. It works for me but I do not begrudge any developer/architect who does not use it.

The embarrassing thing to me is that this arrogance is something I have willingly subjected myself to on twitter. The other really embarrassing thing is that I am probably just as guilty of these heinous war crimes. After following various better known bloggers on twitter, I found myself getting more and more irritated by the various tweets and retweets that were constantly breaking my train of thought, some of the most annoying of recent times are:

“back to developing stories again, ohhhh yeah”

“Test code is just important as the production code, and it needs to be refactored just as often.”

“Just refactored my Trial Balance code from 640 lines of code to 448. When I was ready to test, everything worked the first time around! Yay!”

“if you could punch a singleton, well, I would simply concede that you are the most amazing programmer ever.”

My answer to the above is GFY and stop taking yourself so seriously, you are just as flawed as the rest of us or you would not be on this stupid medium.

Worse than actually tweeting the above is retweeting the above. The sycophantic nature of twitter is possibly more annoying than the holier than thou aspect. It saddens me to see grown developers :-) of the community local to me go weak at the knees when in the twitter presence of somebody American with a blog. Get a life please.

Before I leave twitter, I want to mention a third and equally as sad breed of tweet that we get, the nonsensical tweet. Examples of which are:

“Wasabi peanuts FTW!”

“Got a cold today, feeling tired”.

My answer is the same as before GFY.

In reality twitter is just another reification of an echo chamber that is defined by the fact that you are following people of a similar mind set. If I sound bitter it is only because I am still struggling to combine the words twitter and bitter into a legible word that I will use for the title of this post.

Just to prove how hypocritical I am, I am going to promote this blog post on twitter.

Another hackle I have back at the arrogance of certain developers is this thread about fluent interfaces we found on the ALT.NET mailing list. I personally hate fluent interfaces that are littered with lamdas but that is another blog post. What annoyed me about this was the arrogant almost prose like post from matt Hinze:

“Would like to chime in here - fluent interfaces that are easy to read
are nice but that shouldn't be the goal. The goal should be making
code easy to write.

Fluency is an output; we achieve fluency writing the code not reading
it. One who can only read a foreign language does not claim to be
fluent in it.”

One would like to tell you where to stick this. I doubt you seriously believe this so I really have no idea what benefit there is from posting such a shambolic comment that you tried to refute you later.

Other random irritations are Roy Osherove’s discomforting Leadership series of blog posts. This arrogant know-it-all seems to think managing a group of computer geeks is about asserting yourself sergeant major style. I’ve personally led a life were previously I have had contact with the darker walks of life and certainly not the salubrious surroundings that I have transgressed to in my reincarnation as software developer. Brother would I like to put you in some of those positions and find out how you lead your way out of that. I found the following quote about team leadership totally stomach wrenching:

“If a developer comes to you asking about what a specific API of the application infrastructure might look like - don't follow your initial feeling. Don't give them your idea of what a good API for that part of the app might look like. Instead, ask them to come up with 3 different possible designs”

3 possible designs, for real? Sort it out mate, you have disappeared up your own ego a long time ago. Such advice is really better suited for the toilet. How about producing some working software you prat?

Yet again we find these great(?) developers more concerned with petty organisational paradigms that are inward facing and really do nothing for the external behaviour or the saleability of the products we work on.

Horn Rant and a cry for help

This is a recession busting blog post, you get two opposing emotions in the same blog post. I am ranting at the community and asking for help from the community at the same time. Look upon it as an unusual social experiment.

Further more, I am writing this post for a few reasons:

1. As a cry out to the community for some help with the maintenance side of horn


2. A cathartic aside to myself in order to vent my frustrations with the project or perhaps my failings at generating enough interest or perhaps providing a less than optimal solution to the problem.


3. A bit of a shout or a moan at the recent trend of many OSS projects changing SCM or build tool in a group like nature that resembles a herd.

A lot of the OSS projects have suddenly changed from subversion to git. I find it quite a stretch of the imagination to believe that each of the new git converts made this choice individually and did not follow on from (a)nother OSS project doing the same. The obvious pattern being once one flips, you can bet your bottom dollar that several will make the same decision based more on envy or curiosity than sound judgement. If the move to git had been spread over a larger timescale then I would not have formed this opinion but the close proximity of the migration of the various OSS projects leads me to the last comment.

A lot has changed in a short time with the descriptors and with my day job thankfully so busy right now, I have totally lost track with all the movements.
MVCContrib has changed, rhino has changed and sharp architecture has changed to name but three. I also noticed a recent thread on the castle development list were people were getting equally hot and bothered about a similar change. I’ve observed Jimmy Bogard tweeting that automapper will move to git and I have even had people ask me when is horn moving to git? We have at the most about 5 active developers, what the hell do I need DVCS for? Somebody please tell me this is not the herd talking here.

One of the objectives of horn is to shield the developer from the SCM details and the various build tools that each OSS will inevitably favour and change on a less than predictable basis.

We could really do with some people to take charge or help with the upkeep of the descriptors. Without community input horn is not going to work. To be honest, if it does not work then so be it, at least we tried and got reasonably far or at least got further than most in the .NET space in what is the most puzzling development problem I have ever faced. If you are interested in the challenge, I urge you to get involved, please join the Horn user group.

For those not in the know, the horn descriptors are the database of package or project information that manifest themselves as DSL files on the client machine. For example below is the automapper descriptor. The horn runtime knows after parsing this file which SCM to get the files from and which build engine to use in order to build the source.

1install automapper:
2    get_from svn("http://automapperhome.googlecode.com/svn/trunk/")
3    build_with nant, buildfile("AutoMapper.build"), FrameworkVersion35
4
5    with:
6        tasks full
7
7    build_root_dir "build"
8    shared_library "lib"

We could also do with code patches for some of the new build engines like psake which I really have no wish to learn and could do with somebody in the know to enable psake support for horn.

One of the huge disappointments with horn is that I thought we might get some sort of buy in or even recognition from some of the bigger players in .NET OSS but it seems people get more excited about updating their SCM to DVCS or build engine to rake or powershell or whatever is du jour than providing a standard means for the community getting it’s binaries and perhaps alleviating the upgrade path which as stands is excruciating.

I do have some sympathy with the want to upgrade to the new and shinny, after all OSS is meant to be fun, you get to do things here you might not get a chance to do. git does not work on the corporate model and you might not get a chance to use it otherwise. I also have total respect for anybody who sacrifices their spare time for OSS or the community as a whole. I also do buy into the logic of DVCS (distributed version control system) but I am not sold on git or maybe it is that I am not sold on the tooling and I am definitely not sold on github. I do not like the git tooling period, and my limited experience of github seems to suggest that it can go down enough times to suggest it will be frustrating. My DVCS of choice would have been with mercurial. It has google support and you can guarantee the google infrastructure will not be down that often. But hey Ruby On Rails uses git so it must be good, right? That said, I am not suddenly going to change SCM just because another project has, I need sound reasons to do so.

Not a lot can be done about this, developers including myself will always want to use the shinny and new but essentially my interest in the project is dropping and maybe it is just low down in the wish list of the .NET OSS space or maybe somebody can come up with a better solution. I am willing to share what I have learnt with anybody wanting to mount an attempt at providing a soution.

I am really not sure how much more of my ever decreasing spare time I can put into the project. I have an expectant girlfriend and my own business to run, OSS is dropping down my priority list.

I will say this though, my respect for the contributors of OSS projects has risen tenfold, the very fact that we have Nhibernate, castle and rhino and it is free is mind blowing. I urge every developer out there to think twice before writing a lazy assed post to an OSS forum along the lines of BUGZ, PLEAZZE HELPP MEEE. If you have a query, first search the forum. Nine times out of ten, you will find the answer and if not provide a detailed description or better still, a failing test if you can.

I almost feel better after this rant. Cathartic it was.

If any of this is of interest to you then please join the Horn user group for updates or check out the source here.

Horn Evolution

I have some exciting news that will really help take horn forward to the next step of its evolution.

The current incarnation of horn as a client tool is proving just too cumbersome to really reach any sort of mass appeal. As with any client application, the number of different environmental factors that one client machine can have make it irritating, error prone and less likely to succeed in this form. Horn as a server tool negates the need for the code to run on every different client configuration.

The internal mechanics of horn also make it less appealing as a client tool. horn downloads a lot of source code onto the client machine before each build and this is not preferable for a lot of people who simply want the binaries and not the pile ofsource code that accompany such a build.

I have been mulling over moving horn to the server for some time and I am very pleased to announce that we have had a very generous offer to provide the how in respect to the physical hardware for horn to run on the server.

The good people of iMeta have agreed to give us some much needed server space in their infrastructure to take horn to the next level. We have not really got down to the specifics of the partnership but it is enough to say that if we develop our end then they will give us a slot to make the next step a reality.

There is no doubt that horn is an ethically sound proposition. Anybody who has experienced the versioning hell that we have set out to eliminate knows that put simply the disparate OSS bits do not play together. I take my hat off to iMeta for having such faith in backing us in our quest to take the friction out of OSS adoption and maintenance thereafter.

I would like to especially thank Hadi Hariri for orchestrating the partnership.

As an aside, I wish that we were getting some feedback from some of the more notable OSS projects out there. I mean projects like castle and Nhibernate. Even a quick “you are crazy” would be better than nothing at all. I think horn is an important OSS .NET project or at least the concept is and I wish for more people to get involved who have deeper roots in the .NET OSS landscape.

OK, that is the good news and now let us get down to specifics of how this will work...............

Rather than downloading the binaries via a command line executable we are going to produce a website that will mirror thepackage tree of horn descriptors. We want the web to mirror the package tree and allow categorised navigation via links or search around the site. Each descriptor will potentially have its own page in the web and on such a page the user will have a link to allow them to download a .zip file of the binaries for that descriptor.


What we are looking for is a very lightweight MVC application with very simple views that will be generated from the horn descriptors (more on that later). We either generate the views or we generate some sort of data format that the views will read from.

Which leads me onto the other new horn server side component. Put simply we are going to create a windows service that is going to recursively crawl round the package tree periodically and build all the descriptors it finds. The service will create or update the .zip files that are available for download from the web.

If any of this is of interest to you then please join the Horn user group for updates or check out the source here.

Breaching The Castle Walls

For those unfamiliar with horn which I am guessing is pretty much everyone, horn is an effort to try and take the pain out of both getting and building open source projects. This also includes resolving the sometimes complex maze of dependencies that exists between projects.

My wish is at some stage to have the ability to be able to drop the introduction to horn because it has a presence in the .NET world. That day if it exists is sadly in the future.

The goal of horn is a very worthy and just cause. Anybody familiar with the pain of updating an open source stack containing Nhibernate, castle and Rhino will know exactly what I mean. For those who do not, it is worth mentioning that there is a very contrived dependency map that exists between these projects that makes this an upgrade path fraught with danger. Think of horn as a ruby gems for .NET or an appget.

The basic workflow of horn is this:

The user happily punches an instruction into the command window that on the surface seems to be a very innocent, uncomplicated and a reasonable request.

The request we are going to dissect is horn -install:castle.facilities.

This awakens the infamous horn.exe into life tasked with the mission of not only retrieving and building the castle.facilities source code but also any dependant components that horn might know about. You may ask yourself “how does horn know” about these dependencies? This would be a reasonable question and somebody asked me recently if the code programmatically did a scan of the project files and auto magically worked out what dependencies went where. Sadly this is not the case. There are many reasons why this is not the case but generally the build scripts (nant) that accompany something like castle contain much more than just compiling instructions that make it practically impossible to simply use csc or MSBuild.

Horn has the notion of build descriptors that are housed in what has been lovingly christened the horn package tree. The realisation of this is a directory of horn DSL files that contain build instructions of how to build not only the requested package which in this case is castle.facilities but also any dependencies. I have previously blogged about the DSL here here and here. The first step for horn is to locate the requested package which in this case is castle.facilities. In my last blog post, I wrote about the challenges faced with splitting the castle code base which is a behemoth of a solution.

I have spent the last week trying to build the descriptors for castle. I now consider that I have a good first iteration of the castle build descriptors which is why I have named this blog post so.

Below is the castle.facilities.boo DSL instance file that horn will use to build the requested package.

1install castle.facilities:
2    description "A castle facility augments the container with new functionality."
3
4    prebuild:
5        cmd "xcopy /s /y \"../Patch\" ."
6
7    include:
8         repository(castle, part("SharedLibs"), to("SharedLibs"))
9         repository(castle, part("Facilities"), to("Facilities"))
10        repository(castle, part("common.xml"), to("common.xml"))
11        repository(castle, part("common-project.xml"), to("common-project.xml"))
12        repository(castle, part("CastleKey.snk"), to("CastleKey.snk"))
13
14    build_with nant, buildfile("Facilities/facilities.build"), FrameworkVersion35
15
16    switches:
17        parameters "sign=true","common.testrunner.enabled=false", "common.silverlight=false"
18
19    shared_library "SharedLibs/net/2.0"
20    output "build/net-3.5/debug"
21
22dependencies:
23    depend "castle.windsor" >> "Castle.Core"
24    depend "castle.windsor" >> "Castle.DynamicProxy2"
25    depend "castle.windsor" >> "Castle.MicroKernel"
26    depend "castle.windsor" >> "Castle.Windsor"
27    depend "castle.activerecord" >> "Castle.ActiveRecord"
28    depend "castle.services" >> "Castle.Services.Transaction"
29    depend "castle.services" >> "Castle.Services.Logging.Log4netIntegration"
30    depend "castle.services" >> "Castle.Services.Logging.NLogIntegration"
31    depend "nhibernate" >> "2.1" >> "NHibernate"
32    depend "nhibernate" >> "2.1" >> "Iesi.Collections"
33
34package.homepage = "http://www.castleproject.org/"
35package.forum = "http://groups.google.co.uk/group/castle-project-users?hl=en"

The main point of interest is the dependencies section (lines 22 to 32). Each line of the dependencies section contains 2 or more parts. The first part will point to another horn package which will have its own DSL file and the second part is the name of the .dll we want to retrieve. In the case of Nhibernate we are able to give a specific version number. At the time of writing horn will go for the trunk build by default but I am not sure if this is practical for the long term practicality of the project. We will have to wait and see.

Horn builds an in memory dependency tree that is devoid of duplication and is ordered in such a way that the package with the least dependencies is built first. The in memory dependency tree is constructed by retrieving each of the dependencies found in the DSL descriptor .boo file and then parsing out any dependencies that may be in this dependency file and so on. Obviously this is a recursive process. If you look at the dependencies section on line 22 of the castle.facilities.boo file listing above, the horn process will load the first dependency file it finds in the dependency section, which in this case is the castle.tools.boo file and parse out any dependencies that might exist in this file. Care is taken not to parse the same file more than once and checks are in place to throw an exception in the case of a circular reference. Another horn contributor Craig Nicol recently blogged about the parsing of the dependency tree here.

An interesting dependency map can be illustrated with the castle.facilities.boo listing above that should hopefully illustrate some of the challenges that are faced when resolving dependencies. When the horn process reaches line 27 of the above code listing:

27    depend "castle.activerecord" >> "Castle.ActiveRecord"

The horn process will load the castle.activerecord.boo file into memory which has a dependency section like this:

1dependencies:
2    depend "castle.tools" >> "Castle.Core"
3    depend "castle.tools" >> "Castle.DynamicProxy2"
4    depend "castle.components" >> "Castle.Components.Validator"
5    depend "nhibernate.search" >> "NHibernate.Search"
6    depend "nhibernate" >> "2.1" >> "NHibernate"
7    depend "nhibernate" >> "2.1" >> "Iesi.Collections"

This will cause horn to load and parse out the build descriptors for each of these dependencies and so on. The data in the build descriptors is parsed into an in memory domain model of build metadata objects that will know how to build their particular package.

Castle facilities is by far the most complex package we have built so far and below is the build list we are left with after horn has created it’s in memory dependency tree of build metadata domain objects:
Here is the actual listing of the horn packages in their exact build order.

• castle.tools


• castle.services


• castle.windsor


• nhibernate


• castle.components


• nhibernate.search


• castle.activerecord


• castle.facilities

I must stress that horn is very much a work in progress and we are not at beta quality yet. Horn will download a lot of souce code to your file system given half the chance. Things can and will go wrong.

In my next post, I will explain how horn achieves the task of building the source and resolving the dependencies of a typical horn package.

If any of this is of interest to you then please join the Horn user group for updates or check out the source here.

Dividing The Castle

For those unfamiliar with horn which I am guessing is pretty much everyone, horn is an effort to try and take the pain out of both getting and building open source projects. This also includes resolving the sometimes complex maze of dependencies that exists between projects.

In my previous post, I promised an update on the status of horn. I need to stay focused and have my eye on the prize this time round.

While developing horn recently we reached quite a puzzling impasse with the interesting dependency map that exists between Nhibernate and castle. The problem is that Nhibernate references castle and castle references Nhibernate.

When upgrading my OSS stack, these are the sequence of steps I perform in order to build this troublesome dependency map:

• Build Castle.DynamicProxy2 and copy the output to the Nhibernate bin directory


• Build Nhibernate and copy to the castle bin directory


• Build castle

The problem we have programmatically with this dilemma is that it is a circular reference. If we modeled this in the Dsl, we would have an infinite loop resulting in a stackoverflow.
note: Here is an overveiw of the horn DSL..

A long debate ensued on the Horn user group and we eventually reached a consensus that we had to somehow split the castle code base up in such a way that we could build individual parts of the castle source and thus avoid the circular reference. The castle code base is quite a beast as anyone who has ever performed an svn update or check out will testify, there are a lot of interwoven, inter-project dependencies between this behemoth of a solution. We needed someway of building the castle.DynamicProxy2.dll and any dependencies it might have on the code base. The default.build nant file that builds the castle source code was written to build all projects and has no hooks for building sub-projects. We would need some underhand tactics and some more Dsl trickery to somehow change the castle nant build script with changes of our own.

Here is the Dsl descriptor which houses the instructions that is needed to build the newly birthed castle.tools package that will produce the Castle.DynamicProxy2.dll as part of its output.

1install castle.tools:
2    description "Dynamic Proxy Generator for the CLR."
3
4    prebuild:
5        cmd "xcopy /s /y \"../Patch\" ."
6
7    include:
8         repository(castle, part("Tools"), to("Tools"))
9         repository(castle, part("Core"), to("Core"))
10        repository(castle, part("common.xml"), to("common.xml"))
11        repository(castle, part("common-project.xml"), to("common-project.xml"))
12        repository(castle, part("CastleKey.snk"), to("CastleKey.snk"))
13
14    build_with nant, buildfile("Tools/Tools.build"), FrameworkVersion35
15
16    switches:
17        parameters "sign=true","common.testrunner.enabled=false", "common.silverlight=false"
18
19    shared_library "SharedLibs/net/2.0"
20    output "build/net-3.5/debug"
21
22 package.homepage = "http://www.castleproject.org/"
23 package.forum = "http://groups.google.co.uk/group/castle-project-users?hl=en"

The first point of interest in this Dsl instance is at lines line 4 and 5

4    prebuild:
5        cmd "xcopy /s /y \"../Patch\" ."

A prebuild block was authored that gets parsed into the horn metamodel. Put simply, the code will attempt to execute any DOS commands that are placed in the prebuild block. This is a very temporary measure as the scope for danger is big if we let users enter their own DOS commands here. We will replace them with actual Dsl instructions at a later refactoring and when we know exactly what to create.

The intention of the xcopy is to patch the castle nant files with modifications we made that allow us to build this fragment of the castle code. We are acutally quite crudelly copying modified copies of the nant files over the freshly retieved real castle files. Crude as it is, it really was the only way bar petitioning the good people of castle to change their code or allow us to supply patches. This was quicker and more polite.

I then went leftfield and made a refactoring that is described in the include block of code:

7    include:
8         repository(castle, part("Tools"), to("Tools"))
9         repository(castle, part("Core"), to("Core"))
10        repository(castle, part("common.xml"), to("common.xml"))
11        repository(castle, part("common-project.xml"), to("common-project.xml"))
12        repository(castle, part("CastleKey.snk"), to("CastleKey.snk"))

The include block contains instructions of what parts of which project we want to build. We can retrieve directories or files from what has been christened a repository.

A repository in the context of horn is a node in the horn package tree that can be thought of as the whole of the code base. In this example it is the entirity of the castle trunk. All the parts are retrieved from the castle package tree node. The castle package tree node or repository will synchronise itself with the remote svn repository if the code is out of date. This opens up the opportunity of pulling together different parts of different repositories into more interesting and user defined builds.

The moral of this story is that although we were at first hit with a very difficult problem, the solution ended up opening up many opportunities for horn. I was quickly able to add a further build descriptor for castle.windsor.

The net result is that we are able to build Nhibernate and the relevant parts of castle. Next up, I want to tackle the infamous Rhino stack. Manually building Rhino is one of the reasons I was keen to tackle horn. I have had more problems building this stack than any other, much as I love the end result. This is a fight I intend to win by hook or by crook.

On a selfish note, I really like the way horn Dsl has evolved but then, I would.

The funny thing is, just after completing this work, the castle developers started debating splitting the castle code base as is discussed in this thread.

If anybody from castle is reading this thread then they should consider using horn as a means of pulling their split up stack together and building.

If any of this is of interest to you then please join the Horn user group for updates or check out the source here.