+972 52-548-6969
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
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?
where can we see its progress? if i click show log on the trunk, i see nothing
Consider Mercurial instead of Git. It's (pretty much) the same thing, only more "human friendly". Have a look and tell us your opinion. =)
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
Have you tried the indirect dependency mode that will pinpoint this sort of 'indirect' dependencies issue?
Oliviery,
You can check it out here:
http://github.com/ayende
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
Oren, does this mean rhino-tools.svn.sourceforge.net/.../rhino-tools is deprecated?
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
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.
@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.
" * Make it simpler to treat each project independently
"
Although it's certainly more work for you, I'm glad to hear this.
Comment preview