Marcus, Horn can and should be used.
But not everything is compiling and I honestly do not know where to point the descriptors to. My points are this and please choose to ignore them as the ramblings of a mad Irish man: 1. Creating multiple versions quickly like Castle.Core 1.2, 1.3, 1.4 is confusing. 2. Having multiple versions of other castle libraries like castle.windsor with different named versions 2.1, 3.0 is confusing. 3. No way of being to use multiple versions of the castle stack is not good at best. As I said earlier, I love Castle but it is becoming impossible to use. I have heard this criticism from others. It is useful feedback and if nothing else, an interesting problem to solve. Cheers Paul Cowan Cutting-Edge Solutions (Scotland) http://thesoftwaresimpleton.blogspot.com/ On 4 March 2010 14:35, Markus Zywitza <[email protected]> wrote: > Hm, I was hoping that HORN would be the solution for that kind of > problem... > > I had this upgrade paralysis back when Castle still was a single trunk > project, I just had it with Castle, NH and Rhino alone. To overcome > it, I created a NAnt file that did what HORN does now. > > -Markus > > 2010/3/4 Paul Cowan <[email protected]>: > > 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 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? > > > > 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. > > > > If nobody else sees this as a problem and just an occasional challenge > then > > I will be quiet. > > > > 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? > > > > Cheers > > > > Paul Cowan > > > > Cutting-Edge Solutions (Scotland) > > > > http://thesoftwaresimpleton.blogspot.com/ > > > > > > > > On 4 March 2010 14:04, Michael Maddox <[email protected]> > wrote: > >> > >> Paul, > >> > >> Managing dependencies is time consuming at best, extremely difficult at > >> worst. > >> > >> That is why so many people avoid dependencies like the plague. > >> > >> Krzysztof said that he thinks two months is long enough to update > >> dependencies, and while that feels reasonable, it's just not. > >> Updating dependencies is a distraction. It doesn't, in general, make > >> end users lives better. It's "make work". > >> > >> Any project focused on making user's lives better is going to avoid > >> dependencies and waste as little time managing dependencies as > >> possible. That means they aren't likely to upgrade to the latest > >> version of a dependency unless there is a solid user focused reason to > >> do so (and personally I always fret about regressions from new bugs in > >> the new version). > >> > >> So, if you are forced to take on dependencies, your only recourse is > >> to aggressively manage those dependencies. > >> > >> I think HornGet is a fantastic piece of engineering and I honestly > >> don't know enough about Ruby to know why life is theoretically better > >> there, but I know this problem fundamentally can't be made to go away. > >> > >> It should be possible for any reasonably experienced developer to take > >> the Castle stack, create a fork of each project (from a tag, release, > >> branch, trunk, wherever), and integrate them so they all work > >> together. This isn't a version number issue or a release cycle issue > >> so much as it is a "does the thing compile and pass all integration > >> tests" issue. > >> > >> It takes time and effort and doesn't necessarily feel like things are > >> moving forward. > >> > >> -Michael Maddox > >> http://www.capprime.com/software_development_weblog/ > >> > >> 2010/3/3 Paul Cowan <[email protected]>: > >> >>> What else do you think could Castle project do? > >> > > >> > I always wonder why this does not seem to be such a big problem in > Java. > >> > How do they not have these versioning problems given their inherent > >> > similarities? > >> > > >> > As far as castle is concerned, it would make sense to have a versioned > >> > build > >> > of everything. That is we can say that all castle libraries are at > the > >> > same > >> > version. > >> > > >> > At the moment, we have 3 versions of castle core 1.2, 1.4 etc. and > >> > different > >> > versions of castle windsor 2.1, 3. > >> > > >> > This seems very disconnected. Should there not be a build that is all > >> > at > >> > the same version? > >> > > >> > In the grand scheme of things, I think ALL .NET OSS needs to work > >> > together > >> > to try and alleviate this nightmare. There are a multitude of great > >> > initiatives being held back by all working at different versions of > >> > shared > >> > libraries. > >> > > >> > Releases should not happen every month, that is, we do not say there > is > >> > 2.1 > >> > finished this week, lets go straight on to 3 next and 3.1 the week > >> > after. > >> > > >> > Maybe working to stricter interfaces would help for binary > >> > compatibility. > >> > > >> > There are soooooooooooo many different versions of the boo libraries > >> > kicking > >> > around it is crazy. > >> > > >> > I like the idea of a shared repo where people can pull their shared > >> > libraries from rather than just going to the OSS project of choice and > >> > pulling down the latest which is why we are where we are. > >> > > >> > Getting a delivery mechanism for .NET OSS like ruby gems is currently > >> > practically impossible due to .NET's assembly model and the wild west > >> > approach of dependency management. > >> > > >> > I know because I have tried! > >> > > >> > Any thoughts? Am I alone in thinking this is something that really > >> > needs > >> > cracked on a large scale? > >> > > >> > Cheers > >> > > >> > Paul Cowan > >> > > >> > Cutting-Edge Solutions (Scotland) > >> > > >> > http://thesoftwaresimpleton.blogspot.com/ > >> > >> -- > >> 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]<castle-project-devel%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/castle-project-devel?hl=en. > >> > > > > -- > > 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]<castle-project-devel%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/castle-project-devel?hl=en. > > > > -- > 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]<castle-project-devel%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > -- 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.
