Horn package manager and Sharp Architecture

2 views
Skip to first unread message

dagda1

unread,
Jul 29, 2009, 11:17:21 AM7/29/09
to S#arp Architecture
Hi all,

I am not sure if you guys have heard of the horn package manager, but
we are trying to be a ruby gems, maven or appget with the main
difference being that we build from the source code as opposed to
binary or code file distribution. Building from the source is the
only way I have ever managed to rebuild my software stack of
Nhibernte, Castle, Rhino etc.

Here is the google code page for horn:

http://code.google.com/p/hornget/

The page has a number of links to blog posts I have written, a link to
the user group and a link to a video of a presentation I did at the
Dsl DevCon.

We are able to not only build SharpArchitecture but also resolve any
dependencies through horn.

For instance if you build horn and cd to the horn.exe, you can issue
the following command:

horn -install:sharp.architecture

Behind the scenes, this command will hunt out a Dsl descriptor of
build information for the selected package, in this case
sharp.architecture. The sharp.architecture package is currently one
of our biggest and the Dsl descriptor looks like this and please note
the dependencies section:

install sharp.architecture:
description "This is a solid architectural foundation for rapidly
building maintainable web applications leveraging the ASP.NET MVC
framework with NHibernate."
get_from svn("http://sharp-architecture.googlecode.com/svn/trunk")
build_with nant, buildfile("SharpArch.patch.build"),
FrameworkVersion35

with:
tasks compileandcopytobuild

shared_library "bin"
build_root_dir "build"

dependencies:
depend "castle.tools" >> "Castle.Core"
depend "castle.tools" >> "Castle.DynamicProxy2"
depend "castle.windsor" >> "Castle.MicroKernel"
depend "castle.windsor" >> "Castle.Windsor"
depend "castle.services" >>
"Castle.Services.Logging.Log4netIntegration"
depend "castle.components" >> "Castle.Components.Validator"
depend "nhibernate" >> "2.1" >> "NHibernate"
depend "nhibernate" >> "2.1" >> "NHibernate.ByteCode.Castle"
depend "nhibernate" >> "2.1" >> "Iesi.Collections"
depend "fluentnhibernate" >> "FluentNhibernate"
depend "nhibernate.linq" >> "Nhibernate.Linq"
depend "nhibernate.validator" >> "NHibernate.Validator"
depend "mvccontrib" >> "MvcContrib"
depend "mvccontrib" >> "MvcContrib.FluentHtml"
depend "mvccontrib" >> "MvcContrib.ModelAttributes"
depend "mvccontrib" >> "MvcContrib.TestHelper"
depend "mvccontrib" >> "MvcContrib.Castle"

package.homepage = "http://code.google.com/p/sharp-architecture/"
package.forum = "http://groups.google.com/group/sharp-architecture"

Horn will download all the required source code for the package and
the dependencies and then build all the dependencies based on an
algorithm. It will then copy the .dlls into the sharparchitecture's
lib folder and thus update the software stack. As you can imagine
this is not the fastest process in the word

We are not beta complete so use horn at your own danger but I wonder
if this is something would interest you guys? If so I would love
your feedback.





Paul Cowan

unread,
Jul 29, 2009, 11:30:56 AM7/29/09
to S#arp Architecture
I am just remembering that the fluentnhibernate build will break when running from horn if you do not have the following ruby gems installed:
 
gem install rake
gem install activerecord
gem install rubyzip
gem install rails
 
We have not found a SAFE way of calling these commands from horn yet.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/7/29 dagda1 <dag...@scotalt.net>

James Gregory

unread,
Jul 29, 2009, 11:34:15 AM7/29/09
to sharp-arc...@googlegroups.com
Out of interest, are you not just building FNH with MSBuild now?

Paul Cowan

unread,
Jul 29, 2009, 12:06:09 PM7/29/09
to sharp-arc...@googlegroups.com
Not at this exact time, we added rake support and testing it on FNH was the proof of the pudding.
Now it works we might change it back to msbuild.
Rake is a bit of a prickly one for OSS, I removed the rake files from horn and replaced them with nant because I got complaints about having to install ruby and rake.
I hate nant personally but at least it can be added to the distribution.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



Paul Cowan

unread,
Jul 29, 2009, 12:33:38 PM7/29/09
to sharp-arc...@googlegroups.com
I have changed the FNH descriptor back to msbuild, so it should no longer require rake and the gems.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/7/29 Paul Cowan <dag...@scotalt.net>

Kyle Baley

unread,
Jul 29, 2009, 1:41:29 PM7/29/09
to sharp-arc...@googlegroups.com
I remember looking at HORN when I set up the CI for it. Sounds ambitious but useful. Odd that the dev community would complain about a dependency for a project that manages dependencies...

From the descriptor, it appears that you can specify a version number for the dependency, yesno? What if you don't specify a version? Will it take the latest?

How would using HORN compare to, say, including the dependent libraries with the project itself the way it's done now?

Paul Cowan

unread,
Jul 29, 2009, 3:56:09 PM7/29/09
to sharp-arc...@googlegroups.com

That is correct, if no version number is selected then the trunk is retrieved.

Horn is not a replacement for distributing the binaries of the dependencies but more for rebuilding them.  Say for example castle dynamic proxy changes, you will need to rebuild everything to get the latest version.  This will involve getting all the source from the particular svn or whatevr.  You then have to decipher which nant switches to pass before copying .dlls to various shared libraries.  Horn does all this automatically.  If you want to use nhibernate 3.0 then horn will get and build nhibernate 3.0. And you can also rebuild nhcontrib and rhino for example to the latest nhibernate version.

On Jul 29, 2009 6:50 PM, "Kyle Baley" <ky...@baley.org> wrote:

I remember looking at HORN when I set up the CI for it. Sounds ambitious but useful. Odd that the dev community would complain about a dependency for a project that manages dependencies...

From the descriptor, it appears that you can specify a version number for the dependency, yesno? What if you don't specify a version? Will it take the latest?

How would using HORN compare to, say, including the dependent libraries with the project itself the way it's done now?

On Wed, Jul 29, 2009 at 12:33 PM, Paul Cowan <dag...@scotalt.net> wrote: > > I have changed the F...

Kyle Baley

unread,
Jul 30, 2009, 3:48:39 PM7/30/09
to sharp-arc...@googlegroups.com
I see. So it's more for the developer *working* on Sharp Architecture rather than the one using it?

Paul Cowan

unread,
Jul 30, 2009, 4:30:34 PM7/30/09
to sharp-arc...@googlegroups.com

It's goal is to take the pain out building or more likely rebilding a complex interconnected software stack.  We have implementations for rake, msbuild, nant and svn and git on the scm side.

This is a pain point I have suffered many times in order to apply a bug fix or to switch from a branch to the nhibernate trunk for example.

The exmaple I always use is when asp.net went from beta to release.  Mvccontrib was built against the trunk version of castle.  I and countless others use nhibernat, nhcontrib and rhino.  In order to use the latest mvccontrib we had to rebuild everything that used castle.  Horn will do this for us.

it also means we can get the latest .dlls for any oss without having to know the svn or build details that has a descriptor just by requesting them, e.g.

Horn -install:rhino

Horn -install:moq

Horn -install:fluentnhibernate

Etc.

A bit like ruby gems but we download and build the source first.

On Jul 30, 2009 8:48 PM, "Kyle Baley" <ky...@baley.org> wrote:

I see. So it's more for the developer *working* on Sharp Architecture rather than the one using it?

On Wed, Jul 29, 2009 at 3:56 PM, Paul Cowan <dag...@scotalt.net> wrote: > > That is correct, if n...

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subs...

Billy

unread,
Jul 30, 2009, 4:36:19 PM7/30/09
to S#arp Architecture
Putting together new release packages of S#arp Architecture is always
a bit painful due to trying to get all the dependencies in synch. I
will certainly give HORN a try the next time around.

Billy McCafferty


On Jul 30, 2:30 pm, Paul Cowan <dag...@scotalt.net> wrote:
> It's goal is to take the pain out building or more likely rebilding a
> complex interconnected software stack.  We have implementations for rake,
> msbuild, nant and svn and git on the scm side.
>
> This is a pain point I have suffered many times in order to apply a bug fix
> or to switch from a branch to the nhibernate trunk for example.
>
> The exmaple I always use is when asp.net went from beta to release.
> Mvccontrib was built against the trunk version of castle.  I and countless
> others use nhibernat, nhcontrib and rhino.  In order to use the latest
> mvccontrib we had to rebuild everything that used castle.  Horn will do this
> for us.
>
> it also means we can get the latest .dlls for any oss without having to know
> the svn or build details that has a descriptor just by requesting them, e.g.
>
> Horn -install:rhino
>
> Horn -install:moq
>
> Horn -install:fluentnhibernate
>
> Etc.
>
> A bit like ruby gems but we download and build the source first.
>

Paul Cowan

unread,
Jul 30, 2009, 4:48:58 PM7/30/09
to sharp-arc...@googlegroups.com

You got it billy.  It is a genuine pain point.

We are nearing beta completion.  So when you need to upgrade we should be solid by then.

On Jul 30, 2009 9:36 PM, "Billy" <wmcca...@gmail.com> wrote:


Putting together new release packages of S#arp Architecture is always
a bit painful due to trying to get all the dependencies in synch.  I
will certainly give HORN a try the next time around.

Billy McCafferty

On Jul 30, 2:30 pm, Paul Cowan <dag...@scotalt.net> wrote: > It's goal is to take the pain out bui...

> On Jul 30, 2009 8:48 PM, "Kyle Baley" <k...@baley.org> wrote: > > I see. So it's more for the deve...

> On Wed, Jul 29, 2009 at 3:56 PM, Paul Cowan <dag...@scotalt.net> wrote: > > > > That is correct, i...

Hainesy

unread,
Jul 31, 2009, 5:30:52 AM7/31/09
to S#arp Architecture
I can't wait for this to be released fully. I remember losing a whole
day once just to trying to get our project building from the
dependency hell we were in!

Paul Cowan

unread,
Jul 31, 2009, 6:12:25 AM7/31/09
to sharp-arc...@googlegroups.com
>>  remember losing a whole day once just to trying to get our project building from the dependency hell we were in!

I have lost time during every upgrade .

At one point it was agreed enough was enough and horn was born.


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/7/31 Hainesy <hain...@googlemail.com>

Kyle Baley

unread,
Jul 31, 2009, 9:19:58 AM7/31/09
to sharp-arc...@googlegroups.com
I'm kind of going through it now because I want to wedge in NHibernate Search which doesn't have binaries available. Have had to (re)-compile NHibernate Search, NHibernate Validator, Fluent NHibernate, and Sharp in order to get something that will at least work the normal way NHibernate does. Discovered more than a couple of references that point to the wrong location along the way. So yeah, I'll be interested when this is done too.

Paul Cowan

unread,
Jul 31, 2009, 9:41:03 AM7/31/09
to sharp-arc...@googlegroups.com
THis whole upgade process is an absolue nightmare that is only further intensified as more open source is created and depends on each other.

I would encourage anybody who is interested in this to get involved.  Without trying to sound too much "peace and love", my wish is that this is a community initiative where we all try and simplify the nightmare.
 
As with any OSS getting contributors has been extremellly hard.
 
I besiege anyone who this interests to get involved.  We have made good progress but could do with more hands or more feedback.
 
The asp.net mvc dlls and nhibernate 3.0 starting will mean more upgrading or swapping bits around.

Then there are the SCM du jour like git and mercurial that will be added. 

Messing around knee deep in svn, git, rake and nant is not my idea of fun.
 
All the parts should fit together easier.


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2009/7/31 Kyle Baley <ky...@baley.org>
Reply all
Reply to author
Forward
0 new messages