I understand exactly what you are talking about, monorail is bulky and carries a lot of unnecessary weight. I have previously mentioned this as well and got nowhere. Another dead weight on monorail is the activerecord integration, this brings a lot of external dependencies that are not required if you not using it. I think to do this properly we would have to separate each integration assembly into its own VS solution the same way Windsor has the concept of facilities. And the next step would be to have our own d/l manager where the user can tick what they want and it only d/l the required assemblies, something similar to jQuery's one. But this would require a bit more work. Anyway, this topic probably requires its own thread for discussion.
Cheers John On 03/11/2009, at 12:09 AM, Gauthier Segay <[email protected]> wrote: > >> I'm not sure about separating view engines from monorail, why? > > The idea to finely grain the viewengine structure is that there is a > alternative mvc framework that may rely on the same viewengines > > Spark viewengine is an exemple where the core (Spark.dll) is shared > among all dependent projects, also there is a specific assembly to > integrate with specific project (implenting > Castle.MonoRail.Framework.IViewEngine in the case of Castle MR) > > Brail and NVelocity are used as well in mvccontrib but I'm not sure > if the implementation layering is made like Spark > > that specific idea doesn't seem "allright" anymore because I > understand that MR release actually ship with AspView, Brail and > NVelocity. > > But we may want to separate theses, because each have his set of > dependencies that are not needed to MR core which adds weight to the > distrib package > >> So from what I understand each project would have its own >> descriptor checked into its own repository, and the horn server >> would pull this down to build them centrally, is this right? > > the point with horn is all libraries (castle & all) are going to be > located at horn blessed repository/directory so I think it's better to > put up the cleanest layout because there will be many libs. > > I'm willing to contribute to the effort of structuring castle > descriptors, I stumbled on MR yesterday but made a simple descriptor > for cobra language to work (ok easy, no deps). I need to check up the > current state of SVN layout for each of the castle projects > > On Nov 2, 10:31 am, John Simons <[email protected]> wrote: >> New structure looks good, but I'm not sure about separating view >> engines from monorail, why? >> Monorail is ok after relocation. It is building in teamcity. The >> only problem is that you have to create descriptors for all its >> dependent projects first. >> >> So from what I understand each project would have its own >> descriptor checked into its own repository, and the horn server >> would pull this down to build them centrally, is this right? >> >> Cheers John >> >> On 01/11/2009, at 8:26 PM, Gauthier Segay >> <[email protected]> wrote: >> >> post sent prematuraly >> >> I'm currently trying to create castle.monorail.boo but I'm brand new >> to horn descriptors so it's still a poke and try process, I'm also >> unsure of the state of the MonoRail codebase relocation ATM. >> >> I'll try something easier if >> >> Paul, what the best way to rework the package structure to host >> castle >> project descriptors as looking like my previous post? >> >> On Nov 1, 7:22 pm, Gauthier Segay <[email protected]> wrote: >> I'm playing with horn (which has already well served me a few times) >> and would like to put up a better descriptor structure because all is >> currently under ioc folder: >> >> ioc >> castle.microkernel >> castle.windsor >> castle.facilities >> components >> castle.services >> castle.components >> orm >> castle.activerecord >> web >> mvc.frameworks >> castle.monorail >> viewengines >> castle.monorail.viewengines.aspview >> castle.monorail.viewengines.brail >> castle.monorail.viewengines.nvelocity >> castle.monorail.viewengines.spark >> spark >> nhaml >> >> On Oct 31, 7:49 am, John Simons <[email protected]> wrote: >> >> Paul, >> That is great news :) >> Unfortunately, I've been busy with the migration of projects to the >> new structure and haven't done any more horn descriptors for the new >> Castle projects structure. >> I'm also going away for a month and only coming back in December, >> so I >> won't be able to finish them off till then. >> >> Everyone, >> Is anyone else interested in building horn descriptor for the Castle >> projects? I have included in the first post of this thread some >> already that can be used as an example. >> >> Cheers >> John >> >> On Oct 31, 5:30 pm, dagda1 <[email protected]> wrote: >> >> Hi, >> >> I just want to update you on an exciting development with horn that >> will hopefully encourage you to further participate, >> >> We are going to launch the horn website any day now. The horn >> website >> will have downloadable links to zip files of all the projects it >> knows >> how to build. >> >> So at the moment we will have under the category of IOC, the >> following >> relevant sections with regard to castle: >> >> castle.activerecord/ >> castle.components/ >> castle.facilities/ >> castle.services/ >> castle.tools >> castle.windsor >> >> We have a windows service that will once a day build downloadable zip >> files of .dlls for all the descriptors we have. >> >> This means it will not only build the castle.dlls but it will resolve >> it's dependencies also. >> >> A lot, if not most of the other projects built by horn depend on >> castle, for example, the sharp architecture project has the following >> dependencies section: >> >> 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" >> >> I will need to update the descriptors to the new castle structure >> which to be honest, I have lost track of. >> >> I think the horn website will really take away a lot of the pain with >> getting builds of the latest OSS projects out of the hands of the >> user >> who now needs to install a myriad of things like msysgit, psake etc. >> just to get a fresh build. >> >> Buy in from projects like castle is crucial and thanks to John Simons >> for being proactive in this thread. I have struggled to get interest >> in our cause thus far. >> >> I think the website has the potential to be massive. >> >> If you guys can take charge of maintaining your descriptors then that >> would be awesome. >> >> I moved the descriptors to git in order to encourage participation: >> >> http://github.com/dagda1/hornget >> >> The horn website has the potential to be big for all relevant OSS and >> allow people to get latest builds without having to even use >> TortoiseSvn. >> >> Cheers >> >> Paul >> >> On Oct 20, 12:48 am, John Simons <[email protected]> wrote: >> >> Has anyone given any thought on this? >> I'll proceed with creatinghornscripts for all the projects. >> >> Feedback please >> >> Cheers >> John >> >> On Oct 17, 10:59 am, John Simons <[email protected]> wrote: >> >> For some reason thehttp://blog.bittercoder.comlinkseemstobedown: >> ( >> >> Hamilton, have a look athttp://code.google.com/p/hornget/thereisa >> lot of info there. >> >> To get started do a svn gethttp://code.google.com/p/hornget/source/ >> checkout >> Build hornget >> And run it. >> >> Mailing list -http://groups.google.com/group/horn-development >> >> Cheers >> John >> >> On Oct 17, 10:51 am, hammett <[email protected]> wrote: >> >> Interesting. What do I need installed in order to usehorn? >> >> On Tue, Oct 13, 2009 at 2:44 AM, John Simons >> <[email protected]> wrote: >> >> I finally had some time to play withhorn(I've just realised that this >> sentence sounds funny!). >> Anyway, now with the new builds working, I've started creating >> individual >> hornscripts (aka boo scripts) for each project. >> I've attached 2 of the scripts I have so far, more coming soon. >> The scripts build NVelocity and TemplateEngine Component which >> depends on >> NVelocity. >> Just want to know what people think about using this mechanism to >> replace >> the trunk eventually. >> >> Thoughts? >> >> ________________________________ >> Get more done like never before with Yahoo!7 Mail. Learn more. >> >> -- >> Cheers, >> hammetthttp://hammett.castleproject.org/ >> >> >> ___________________________________________________________________________ >> _______ >> Get more done like never before with Yahoo!7 Mail. >> Learn more:http://au.overview.mail.yahoo.com/ > > __________________________________________________________________________________ Get more done like never before with Yahoo!7 Mail. Learn more: http://au.overview.mail.yahoo.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] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
