Actually, we did have all build scripts in a common repository, which we referenced using git submodules (see https://github.com/castleproject/Castle.Windsor/commit/1884d62fc8015bbdc7881402d0250f9c8c1b0614 ) .
But then we decided to just copy the scripts to every project, as git submodules have to be manually initialized with git submodule init; git submodule update (see http://progit.org/book/ch6-6.html#cloning_a_project_with_submodules ). Everyone cloning the repo has to do this to build the project, which is quite annoying, especially for git newbies. So we ended up killing all submodules ( http://www.mail-archive.com/[email protected]/msg07700.html ). -- Mauricio 2011/4/25 Krzysztof Koźmic <[email protected]> > Rafael (and rest), > > actually, we already have the Castle.Common.Targets file in buildscripts > folder in every project. Actually I believe at the beginning the content of > this folder was identical in every project. However now, there are > differences between the projects and maintaining consistency, and > propagating changes across all of them is a pain. > > Can we, in Git extract the contents of the buildscripts folder to a > separate repository and "link" to it from every other repository, like you > can in Subversion? > We would also need to review all the different versions we have by now > across projects, and come up with one unified version. Also the customized > parameters (like version numbers) should be extracted to a separate file and > just those elements. > > I'm happy to work on that if someone with better understanding of MsBuild > and Git is willing to help me out. > > Krzysztof > > > On 25/04/2011 9:05 PM, Rafael Teixeira wrote: > > +1. > > Probably we should have a castle.project.targets file with most of this > customizations, so that adding a few properties and including that targets > file would convert a project to the new build scheme (DRY). > > I think all the tools we need (git, nuget, etc..) have command-line > interfaces that can achieve what we need from msbuild. Having refreshed a > task wrapper project for NUnit myself ( > https://github.com/monoman/MSBuild.NUnit), I think it normally doesn't > "pay the costs" to create specific msbuild tasks, as csproj/msbuild tweaking > is normally left to more hardcore guys which feel fine just 'exec'ing a > command line tool, thus having full-control of the tool features. > > Just some ramblings from my experience on some other large .NET projects. > > Rafael "Monoman" Teixeira > --------------------------------------- > "The most exciting phrase to hear in science, the one that heralds new > discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" > Isaac Asimov > US science fiction novelist & scholar (1920 - 1992) > > > 2011/4/25 Krzysztof Koźmic <[email protected]> > >> I haven't looked beyond putting Nuget package for Windsor 2.5.3 out, >> something that was frequently requested. >> >> I would *love* to have the release process automated (to a point where I >> git push to a new tag and our TeamCity recognizes that, and runs a release >> build that does everything, including release packaging, releasing to SF, >> nuget and OW, branching (if new branch is needed, that is it's not a point >> point release and few other things I forgot, like updating the website in >> all 3 places.)) >> >> I *strongly* prefer giving MsBuild a fair shot before trying any other >> build solution, mostly because MsBuild is out of the box, it's .NET and many >> developers will flat refuse to install Ruby in order to build a .NET >> project. >> >> I think the scripts we have are really well and cleanly written and while >> I'm nowhere near as proficient at working with them as Roelof is, I've been >> able to tweak them on several occasions, same as I'm sure everyone else on >> the team would be. >> >> This however reminds me of another problem I've had, and we'll continue >> having, that is keeping consistency in build scripts among projects. >> I've mostly worked with Core and Windsor and all changes and tweaks >> introduced in one project had to be manually copied to the other one. As we >> have many more projects I'm sure trying to deploy changes to build process >> all across the board would be nothing short of a nightmare. >> >> Can we please consider some options for automated sharing the build files >> among all of our projects so that we only change things once and that change >> gets propagated to every project? >> >> I think it might also be beneficial to have a wiki page that >> a) documents how our build works and how it should be used >> b) documents customizations we've made to .csproj files so that it's easy >> to add a new project and get it to work with the build >> >> Krzysztof >> >> >> On 25/04/2011 7:49 PM, John Simons wrote: >> >> I would much rather use rake then msbulid. >> No offence to Roelof but currently I think the only person that can >> maintain those scripts is him and I don't believe this is a good situation. >> I think Krzysztof is trying to hook up nuget and ow to our build + >> automate most of it, how is that going? Is msbuild working for this? >> >> Cheers, John >> >> On 25/04/2011, at 5:36, Henry Conceição <[email protected]> >> wrote: >> >> About the build: I don't like the ideia of obligating everyone to have >> ruby + rake in order to build the tx stuff. Probably we will restore >> the msbuild and get rid of the rake scripts when we merge the changes >> on the master repo. >> >> On the 3.5 matter: At least for me, we can drop de support for it. >> >> >> >> Cheers, >> Henry Conceição >> >> >> >> On Sat, Apr 23, 2011 at 12:44 PM, Henrik Feldt <[email protected]> wrote: >> >> Yup, a merge it is. They are merged in my repository now. >> >> >> >> >> The rest in this letter is about the upcoming alpha. >> >> >> >> >> Docs: >> >> >> I have added docs to the wiki as well on my repo. >> >> >> >> >> Building: >> >> >> Both projects have been rewritten, based on the previous ideas. This >> >> includes using rake for the build – using it makes me about 10 times as >> >> productive when writing the scripts. >> >> >> >> >> Versioning: >> >> >> In the rake scripts I have set up build-number versioning like that >> >> NHibernate uses, so that >> >> >> 100x is alpha >> >> >> 200x is beta >> >> >> 300x is rc >> >> >> 4000 is ga. >> >> >> >> >> So e.g., currently I’m building 2.9.9.11215 at 3 pm, or 2.9.9.1001 for >> the >> >> first alpha. >> >> >> >> >> The versioning for private builds uses the day of the year and the hour >> as >> >> the build number. >> >> >> >> >> Sadly: >> >> >> Right now I’m just working against .Net v4.0. There’s no real problem >> >> re-targeting 3.5. >> >> >> >> >> Code contracts: >> >> >> I’ve done both with MS code contracts for good or bad, but only debug >> builds >> >> have the contracts. In my opinion it’s nice for showing intent around >> >> interfaces. The most prominently used part is that of the static >> >> verification, the part which doesn’t compile into the assembly. I believe >> >> they work very well with unit tests as well, as one only tests allowed >> >> functionality as opposed to disallowed functionality that throws >> exception. >> >> >> >> >> People use the debug build with contract assertions or the release build >> >> without any alterations. >> >> >> >> >> Alpha TODO: >> >> >> Finish build script for building nuspecs with lib and tools. Perhaps a >> >> transform file for adding AutoTx and the new NHibernate Facility to a web >> >> site. Test this out and release 2.9.9 (perhaps). Set up a build server for >> >> the new rake scripts. Does castle have one that I can use for testing – >> >> TeamCity? I can create its configs. >> >> >> >> >> Release 3.0 TODO File Transactions: >> >> >> I’m aiming to spend a few hours on the file transactions before release >> to >> >> fully integrate it with ITxManager, but the non-file transaction parts >> seem >> >> OK. >> >> >> >> >> Release 3.0 TODO Forking: >> >> >> There is also a bit of problems related to continuation passing when >> forking >> >> dependent transactions through the new [Transaction(Fork=true)] >> >> functionality as tasks are awaited on the finalizer thread if exceptions >> are >> >> not observed on the main thread. >> >> >> >> >> Release 3.1 TODO Retry policies etc: >> >> >> This idea is something I’d like to investigate: possibly retrying failed >> >> transactions through the transaction interceptor. Also, creating a >> >> IHandlerSelector for choosing transient lifestyle components if in no >> >> ambient transaction. >> >> >> >> >> Cheers >> >> >> Henrik >> >> >> >> >> From: [email protected] >> >> [mailto:[email protected]<[email protected]>] >> On Behalf Of Krzysztof Kozmic >> >> Sent: den 15 november 2010 02:30 >> >> To: [email protected] >> >> Subject: Re: Castle.Services.Transaction + Castle.Windsor? >> >> >> >> >> Henrik, >> >> >> What's the status of this? Did you go ahead with the merge? Do you still >> >> plan to? >> >> >> From another department - would you care to have a look at the >> documentation >> >> and expand it to fully cover all functionality of the facility? >> >> http://stw.castleproject.org/Windsor.ATM-Facility.ashx >> >> >> Krzysztof >> >> >> On 23/09/2010 8:52 PM, Henrik Feldt wrote: >> >> >> Hello everyone, >> >> >> >> >> I’m considering merging the code of Castle.Services.Transaction with >> >> Castle.Facilities.AutomaticTransactionManagement/AutoTX. This would >> >> introduce a dependency on Castle.Windsor for Castle.Services.Transaction. >> >> (Another way of saying it is that the IoC-container would be required for >> >> using the transactions project, which it is not now. However, it could >> >> simplify versioning/dll-management slightly). >> >> >> >> >> As of now it is merely a thought: please tell me what your opinions are >> on >> >> whether to merge them or not! >> >> >> >> >> Kind regards, >> >> >> Henrik >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> >> "Castle Project Users" 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-users?hl=en. >> >> >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> >> "Castle Project Users" 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-users?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. >> >> >> -- >> 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.
