Ayende @ Rahien

It's a girl

The complexity of unity

This post is about the Rhino Tools project. It has been running for a long time now, over 5 years, and amassed quite a few projects in it.

I really like the codebase in the projects in Rhino Tools, but secondary aspects has been creeping in that made managing the project harder. In particular, putting all the projects in a single repository made it easy, far too easy. Projects had an easy time taking dependencies that they shouldn’t, and the entire build process was… complex, to say the least.

I have been somewhat unhappily tolerant of this so far because while it was annoying, it didn’t actively create problems for me so far. The problems started creeping when I wanted to move Rhino Tools to use NHibernate 2.1. That is when I realized that this is going to be a very painful process, since I have to take on the entire Rhino Tools set of projects in one go, instead of dealing with each of them independently. the fact that so many of the dependencies where in Rhino Commons, to which I have a profound dislike, helped increase my frustration.

There are other things that I find annoying now, Rhino Security is a general purpose library for NHibernate, but it makes a lot of assumptions about how it is going to use, which is wrong. Rhino ETL had a dependency on Rhino Commons because of three classes.

To resolve that, I decided to make a few other changes, taking dependencies is supposed to be a hard process, it is supposed to make you think.

I have been working on splitting the Rhino Tools projects to all its sub projects, so each of them is independent of all the others. That increase the effort of managing all of them as a unit, but decrease the effort of managing them independently.

The current goals are to:

  • Make it simpler to treat each project independently
  • Make it easier to deal with the management of each project (dependencies, build scripts)

There is a side line in which I am also learning to use Git, and there is a high likelihood that the separate Rhino Tools projects will move to github. Suversion’s patching & tracking capabilities annoyed me for the very last time about a week ago.

Comments

Patrick Smacchia
08/30/2009 09:46 AM by
Patrick Smacchia

I have been working on splitting the Rhino Tools projects to all its sub projects, so each of them is independent of all the others.

I am not sure to understand but are you saying that managing dependencies to decrease how projects depends on each other is a good thing? Btw did you try NDepend for that?

olivierey
08/30/2009 10:18 AM by
olivierey

where can we see its progress? if i click show log on the trunk, i see nothing

Paulo Köch
08/30/2009 11:01 AM by
Paulo Köch

Consider Mercurial instead of Git. It's (pretty much) the same thing, only more "human friendly". Have a look and tell us your opinion. =)

Ayende Rahien
08/30/2009 11:07 AM by
Ayende Rahien

Patrick,

I mean that it is easier to take a dependency on a project in the same repository, it make it easy to work with them together.

The problem is that this creates ties between the projects.

For example, Rhino ETL using Rhino Commons, but then this creates a dependency between Rhino ETL and Castle Windsor, although Windsor isn't used in Rhino ETL

Rhino Security is an even worse example, it make so much use of the architecture in Rhino Commons that you can't make use of it at all without following the UoW pattern as laid out in RC

Patrick Smacchia
08/30/2009 11:40 AM by
Patrick Smacchia

For example, Rhino ETL using Rhino Commons, but then this creates a dependency between Rhino ETL and Castle Windsor, although Windsor isn't used in Rhino ETL

Have you tried the indirect dependency mode that will pinpoint this sort of 'indirect' dependencies issue?

Ayende Rahien
08/30/2009 11:42 AM by
Ayende Rahien

Patrick,

I am not sure that I am following you here. The issue is not so much the indirect dependencies, it is taking a dependency that either change the way you work or bring a lot of additional dependencies with it

olivierey
08/30/2009 03:32 PM by
olivierey

Oren, sorry, but i didn't get it. i have a dependancy to rhino.security trunk in my current project and thinking about updating it. what should i do? should i change to the git repository (you're talking about splitting things up) or should i stay with the svn trunk? ... the question is, witch one do i need, to get the newest pieces from (like the svn trunk) , ... , maybe you can clarify your plans for the future, i think there are some other out there, who also have dependencies.

which tools do you use for git instead of tortoise/visual svn?

thx

Ayende Rahien
08/30/2009 04:06 PM by
Ayende Rahien

olivierey,

Right now, do nothing, I am still playing around with everything.

Consider this just my way of thinking out load.

I'll make proper announcements about everything when I am done.

Mr_Simple
08/30/2009 04:47 PM by
Mr_Simple

@Patrick Smacchia

I own a licence for NDepend and suggest you send a complimentary license to Oren as he may use and write about the product. I this would be a great marketing move on your part.

Steve
08/30/2009 06:05 PM by
Steve

" * Make it simpler to treat each project independently

* Make it easier to deal with the management of each project (dependencies, build scripts)

"

Although it's certainly more work for you, I'm glad to hear this.

Comments have been closed on this topic.