Perhaps I'm wrong - but I was thinking with #1 Initially #1 may not always build. I have everything, including monorail 2, 3 etc. ? I visit github, there's still a pile of repositories to wade through (as a newcomer to Castle)
With #2 We end up with less repositories in github For each of those repo's it's likely they will always build when checked out. As part of #2 there is some time taken to evaluate some of the existing projects and apply some common sense i.e. moving binding into monorail, doing something about projects like template engine / pagination, purging some of the projects without mind share like scheduler (maybe just move them to a single repo called attic?) To me at least doing #2 then #1 made logical sense to me - and some of that rationalization/grouping occurring in #2 would make it easier as a consumer of the castle stack (easier to maintain a mental model when there are less repositories and the inter-dependencies are clear - similar projects are grouped sensibly, less nuget/openwrap packages etc.) I'm probably way off base here as I haven't done a lot with the castle code base in the last 6 months for client projects, but that was certainly the way I felt last time I did attempt to build everything together. Cheers, Alex On Fri, Jun 24, 2011 at 11:05 AM, Kelly Leahy <[email protected]>wrote: > #1 +1 -- if I get a vote ;) > > I also second Oren's comments about submodules - they are an absolute > nightmare. > > I'm confused as to why Alex thinks that #2 would improve the experience as > a castle "consumer". It doesn't seem like to a "consumer" you'd have any > idea which of these choices was selected as the 'winner'. > > Perhaps you could elaborate, Alex? > > Kelly > > On Thu, Jun 23, 2011 at 3:45 PM, Alex Henderson <[email protected]>wrote: > >> Option #2 +1 >> >> Think both are good, but #2 would remove more pain for me then #1 I think >> as a Castle "stack" consumer. >> >> On Fri, Jun 24, 2011 at 6:23 AM, hammett <[email protected]> wrote: >> >>> Option 1: Create a master project that include all other ones as >>> submodules >>> Option 2: Aggregate some as suggested by Krzysztof >>> >>> Please cast your vote. >>> >>> For context: >>> [0] >>> http://groups.google.com/group/castle-project-devel/msg/dee4a8492a09bbec >>> [1] >>> http://groups.google.com/group/castle-project-devel/msg/ccf955d79eb54db0 >>> [2] >>> http://groups.google.com/group/castle-project-devel/msg/264f5e6cb3359a0c >>> >>> -- >>> Cheers, >>> hammett >>> http://hammett.castleproject.org/ >>> >>> -- >>> 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. >>> >>> >> -- >> 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. >> > > -- > 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. > -- 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.
