inline On Thu, Mar 4, 2010 at 8:19 AM, Paul Cowan <[email protected]> wrote: > Thanks for the reply Michael, I (obviously) think this is a conversation > worth having. > But surely you are not saying that in order to use a stack with many castle > parts, I need to, and I quote: > > "create a fork of each project (from a tag, release, > branch, trunk, wherever), and integrate them so they all work > together"
I don't use the entire Castle stack, so I don't know the answer to that question. That's what I would likely do if it didn't just work out of the box and HornGet also couldn't get me there. > I know how to do this and have but I do not want to. It is also intensified > by all the other OSS projects that use castle like nhibernate, rhino and the > rest. Must I retrieve the source of these projects and then use PSake or > whatever else is du jour in order to rebuild my stack? It seems to me that getting things to compile together is much less of a burden than getting things to test successfully together. Sure, the compile issues are annoying, but I'd personally rather deal with them at compile time than run time. If anything, I want the compiler to tell me about all possible problems that come from integrating two components, but that's just not going to happen, ever. > Surely we can do better than that? Other platforms do. > > Ruby is better because the RubyGems package manager takes care of the > installation of reusable libraries called gems. It is a joy to work with. > It is easier in Ruby because they are working with code files and not > binary files but it is truly amazing and shows how poor horn is in > comparison. Let's say .NET was as "capable" as Ruby. What is then left to do? You still need to test whatever dependency code was downloaded, likely with significantly less compiler help than you get in .NET. For me, that would result in writing quite a few new integration tests. Personally, I would prefer to manage my dependencies very explicitly. Automatic downloading of dependencies sounds cool, but I won't necessarily agree that it's "better". I would assume Ruby has some way to manage versions, incompatibility between versions, and compatibility between different versions of dependencies? If so, HornGet can probably take on some of that burden. If not, Ruby's solution sounds like a partial solution to me that would fall down eventually in reality (it could be argued that a partial solution is better than no solution). > If nobody else sees this as a problem and just an occasional challenge then > I will be quiet. I think the complaint is valid. Personally, I just don't have the same view on a solution. I probably need to explore what Ruby is doing more to understand why their approach seems so compelling to so many people. To me, Ruby's solution seems to not reflect the reality of how dependencies work. > At the moment I have a stack that if anything uses too much OSS. I am > paralysed in my upgrade path. > > Surely that last statement is an oxymoron? I don't think this problem is specific in any way to OSS. If anything, OSS makes it simpler because you can fork and fix. Imagine you had a commercial application with dependencies on a dozen different third party commercial components that had interdependencies among themselves. I wouldn't want to touch that project with a ten foot pole. If you take less dependencies on third party components, the downside is that you have a less feature rich application. You may have to reinvent the wheel a few times to avoid taking on a dependency. I think those kind of choices need to be made on a case by case basis, but I think long and hard about each and every dependency that I add to a project. -Michael Maddox http://www.capprime.com/software_development_weblog/ -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
