Horn Project: Removing OSS Cross-Dependency Pains

7

Every now and then as a creative person, you have PWOP moment.  For those unfamiliar with the reference, ‘PWOP’ is the sound that’s made by slapping one’s hand against one’s forehead and is often accompanied by phrases like “I should have thought of that!” or “Of course!  What a great idea!” or even “Duh!”  The Horn Project is one of those moments for me.

The Trouble with Assemble-Your-Own-Infrastructure-Stack

There are a number of things that I love about Microsoft-provided frameworks and a number of things that I don’t like so much, but whatever else you might say about the classes that make up the core of the BCL (Base Class Library, what you and I mostly mean when we say “the .NET Framework”), one thing you do absolutely have to give them credit for is producing a (mostly) cohesive whole that pretty well allows you to use the interrelated pieces-parts of the libraries with (relative) ease.

In fact this is often one of the most seductive arguments in favor of using the MS-provided solution for fill-in-the-blank-here (logging, object-relational-mapping, inversion-of-control, workflow, whatever): that “it all just works together well”.  Reasonable people can (and do!) debate the way some of these parts do their work, but the integration of all these parts has always been a strength of the Microsoft BCL content.

To pick your own ‘stack’ (even if atop the Microsoft-provided BCL framework content), often means having to accept that most OSS projects don’t play together as nicely/smoothly/friction-free as some of the same kind of libraries in the Microsoft-provided stack.  This has long been an impediment the the ‘best-of-breed’ approach to picking your technology stack for a project — to cherry-pick from the list separate components (even when they rely loosely upon each other) often means accepting as a fact of life that you will incur some significant overhead in integrating all the parts of your do-it-yourself (or at least select-it-yourself) technology stack upon which you will be building your solution.

People like me have always accepted that trade-off as a net-positive for our projects; we’ll take the integration pains as a fact of life believing that, on balance, the benefits outweigh the pains.  Some of the pain comes from making the fruits of projects conceived in their individual vacuums play nice together and there isn’t much that anyone can (or perhaps even should) do about that.  But other of the pains are really the result of inter-dependencies between (typically) OSS projects that move at completely different paces and are driven by differing motivations.  And technology can be of help here (or so the Horn Project would have us hope!).

The on-going challenge: Getting Rhinos to Successfully (N)Hibernate in the Castle

Often working with OSS software can mean having to work with versions ‘on the trunk’.  Since OSS projects don’t (usually) commit to convenient release dates so that you can plan your own project lifecycle around them, you frequently cannot wait for the next ‘official’ point-release of an OSS project in order to address an issue that’s currently got you stuck in your tracks.  And since most OSS projects don’t release ‘official’ patches, if you find a show-stopping (for you) bug, report it, and it gets addressed the trunk of the SCC repository (often though not always Subversion) is often the only place to go to get your bug fix.

So what’s a user of an OSS project to do?  Well, you say, its OSS so I can just get the source and build it myself; problem solved!

But now you’re into OSS cross-dependency hell.  Its kind of like DLL-Hell, but because you often don’t have firm version-numbers upon which to rely to puzzle-out concrete build-time dependencies, it can actually often be a lot worse than DLL-Hell.  At least with (Windows) DLL versions, you frequently had access to a wide range of resources that could help to resolve the trouble.

One of the more common (in .NET) instances of this kind of trouble is the Castle-NHibernate-Rhino Tools triumvirate (technically its not so much a triumvirate as a square since another ‘collaborator’ in this mess is often Log4Net with its own version challenges).  Relatively popular (and in fact a big favorite of mine as well — though I am hardly a good barometer of just about anything!), this stack is rife with interdependencies between its parts, all of which need to be properly resolved in order to build them all successfully.

There are any number of other blog posts on how to successfully build all of these from their respective trunks so I won’t bother to retread that again here (hint: its about the sequence of building them and it goes NHibernate –> Castle –> Rhino), but suffice it to say that its a bit more annoying/complex than it needs to be/could be.

Enter: the Horn Project

This exact challenge is the target of a new project designed to ease the building of OSS projects (especially those with inter-dependencies) with an eye towards making interdependencies a little more manageable between them.  This project promises to ease the building of OSS projects by helping to manage the need to retrieve and build other dependent OSS projects for you first, resolve dependencies, and manage the build process on your behalf.

Time will tell if this project lives up to its aspirations, but I will be watching intently and with crossed fingers — looks like a great idea!

Some Links for more information…

Rather than re-hash the content/details, I will just point out the project and list links for some of the details so that you can pursue more info if you are interested.

For more info on the project, to get the source code, join the discussions, or even contribute to the effort, here are some links for you…