I am going to
-
fix latest issues (like 35,36,37,38 and email change issue to be reported by Eric)
-
extract more providers (Portal, Page, Module, possibly i will have to add ProfileProvider, therу are some problem with it)
-
restructure existing providers (into BaseProvider and MsSqlProviders)
-
extremely improve testing workflow (HttpSimulator, WatiN, clear database backup)
-
eliminate some architeсture design defects, refactoring... (classes and functionality duplication, misplace, class names etc)
I am developing all this stuff in my sandbox, trunks, extract_PortalSettingsProvider
Then it will be merged into devint, trunk after it is tested.
I am going to finish with it in week or two.
Then rest from Rainbow a little. And after the rest (if have time):
-
Coding style recommendations (to relieve cheap copies merge and code review / refactoring)
-
Rainbow architecture documentation (Framework, Providers, Core)
-
Rainbow tests architecture documentation (developers manual, deployment manual, integration servers configurations)
-
Autobuild different configurations of Rainbow (Light, Standard, Extended).
-
Finally multiportal issue...
What about yours, guys?
- Added RootFiles for build and inegration organization.
- Changed featured wiki pages and created ContributorRules to be extended
The biggest deal in this is VersionInfo.cs that is:
- inclided in most projects to comlile correct version
- not included in repository
- but created by build process.
- To create the file without running the whole standard build process use command line nant build.version
Finally I have commited the mattschaeffer's security.cs fix to resolve a problem with the recycler where the security.cs was trying to append "recycled" to a stored proc that didn't have a recycle option. It was invented for Rainbow 1.6.
Also, this fix will be adapted and included into Rainbow 2.0, since the workflow was not changed there, just project and namespace changes.
The code for stable version of RainbowPortal 1.6 for .Net Framework 1.1 can be checked out by the following link.
http://rainbow.googlecode.com/svn/NET_1_1/tags/1.6.initial/
This stable version is initial for Google Code project hosting after migation from both sourceforge.net and forge.novell.com.
Also, this link can be branched in developers (do not forget that developers work with https protocol)
The tag was made to continue futher work on Rainbow 1.6 code in code trunk simultaneously saving opportunity to access initial stable code without revision reference.
Cross-posted with the wiki here.
Structure is set in accordance to the following recommendations here in Rahul's blog.
IMPORTANT! To anonymously checkout or export use http protocol. Otherwise if you have been granted with commit rights use https protocol to authorized export, checkout, switch, commit, other repository operations.
The root of the repository is http://rainbow.googlecode.com/svn/* (https://rainbow.googlecode.com/svn/*) Do not checkout or export this url directly, you have to add a relative path to a structure unit for best result. Please remember that the relative paths are case sensitive.
WARNING! There is no http://rainbow.googlecode.com/svn/trunk/ as it shown at standard Google Code page of the Rainbow project
We use our own structure instead of initially precreated structure. It is described below more detailed. You who has rights to commit please follow this structure and never make commits outside your sandbox.
|
|
|
|
| Relative paths for substructure units |
Short description |
|
|
| /wiki/ |
standard google code wiki for the whole repository, can be edited from here |
|
|
| /sandboxes/ |
devepolers' sandboxes with their personal trunks/tags/branches and other required personal structure |
|
|
| /NET_1_1/ |
latest code of rainbow portal for .Net 1.1 |
|
|
| /NET_1_1/branches/ |
|
| /NET_1_1/tags/ |
|
|
|
| /NET_1_1/trunk/ |
latest trunk with its own substructure |
|
|
| /NET_1_1/trunk/ECommerce/ |
ECommerce module |
| /NET_1_1/trunk/Extensions/ |
extensioins necessary |
| /NET_1_1/trunk/Rainbow/ |
site root |
|
|
|
|
| /NET_2_0/ |
unfolded comprehensive structure for working on rainbow for .Net 2.0 version |
|
|
| /NET_2_0/devint/ |
development & integration folder |
|
|
| /NET_2_0/devint/branches/ |
|
| /NET_2_0/devint/tags/ |
|
|
|
| /NET_2_0/devint/trunk/ |
latest devint trunk with its own substructure |
|
|
| /NET_2_0/devint/trunk/Libs |
binary libraries references in Projects and WebSites |
| /NET_2_0/devint/trunk/PrecompiledWeb/ |
precreated empty folder for precompiled web sites |
| /NET_2_0/devint/trunk/Projects/ |
subproject such as Core, Providers etc (see detailed structure at NET_2_0_FoldersStructure) |
| /NET_2_0/devint/trunk/WebSites/ |
folder containing all web sites in use |
| /NET_2_0/devint/trunk/WebSites/Rainbow/ |
the web site (see detailed structure at NET_2_0_FoldersStructure) |
|
|
| /NET_2_0/stage/ |
stage environment with its own separate structure |
|
|
| /NET_2_0/stage/branches/ |
|
| /NET_2_0/stage/tags/ |
|
| /NET_2_0/stage/trunk/ |
|
|
|
|
|
| /NET_2_0/prod/ |
production environment with its own separate structure |
|
|
| /NET_2_0/prod/branches/ |
|
| /NET_2_0/prod/tags/ |
|
| /NET_2_0/prod/trunk/ |
|
|
|
|
|
Rainbow.Tests.GeographicProviderTest cases randomly fail locally on my workstation and on community build server (source.iocluster.com, see failed builds before 292 fixed).
The fails are random and unpredictable, they can appear or not, this is inadmissible.
The first I want to say is - there are extra try-catch blocks in the test cases. The test will fail even without, so we do not get any benefit from this block, but get extra code. If you want to asseert some statements without test case fail after assertion fail, you can use Log String TDD pattern. This pattern is not implemented in NUnit framework and has to be implemented by our own code.
I can remove the extra try-catch blocks myself (and implement the pattern if needed), but first I will wait for MGF's team feedback, because if I do it myself, they will have to merge these changes inthe their sandbox trunk as they are the initial developers of that tests.
Also, if I run tests one by one manually from VS by ReSharper, they are always successful. So I suspect of some TearDown actions are unstable and should be at least reviewed.
svn revisions 55 - 58
Unit tests from the project Rainbow.Tests are now included into community build process.
It can be found by trunk relative path Projects\Rainbow.Tests\Rainbow.Tests.csproj
You can see them at http://source.iocluster.com/site/ccnet_servers/295/ccnet_servers.aspx:
- click there to iocluster - Rainbow devint-trunk link;
- choose the build (it is usually the latest build, but Nunit details and timing are included starting from 283 build);
- click NUnit Details or NUnit Timings links at the right box of build info screen;
- enjoy :-)
Build target are called this.tests.prepare and this.tests.run in the repo root nant.build file
this.tests.prepare target performs the following actions:
- recreates separate database for tests purposes (called by the template rbtests_${this.databaseName}, where ${this.databaseName}='NET_2_0$devint$trunk' for the devint trunk);
- adjusts App.config to set this database in correspondent parameters using App.config.standard as a template (by the trunk relative path Projects\Rainbow.Tests)
this.tests.run target performs the following actions:
- runs the nunit2 task of nant on the Projects\Rainbow.Tests\bin\dll
- saves the test results in Rainbow.Tests.dll-results.xml file of the trunk root to be merged with ither CCNet stuff and be shown by the links described above;
- fails if at least one test failed.
- review and possibly intergate to devint trunk Yannic Smits sandbox branch changes at revision r573 (Yannic, are these changes purposed to intergrate or no?)
- FINALLY! start attempts of multiportal reparing and testing in my own branch, then integrate in into devint trunk.
- vacation (15-24 sep.) - not a contribution, bu planned too ;-)
- integrate Rainbow.Tests to build process at least locally (Jose, it requires creation new database on each run, does not it?)
- come up through the mail server on the source.iocluster.com - to broadcast ccnet build results by email. Rahul, does it require authentication or valid From: address or something else to work properly?
- Review & correct russian & ukrainian localization.
- talk to Jon about his changes at revision 531-535 to know are they really needed in the devint. Jon, it seems to me they are not.
putting providers in right place, and removed them from solution files.
projects still exist in folder though.
web site commit will remove dlls and clean up web.config.
this is a 2 part commit.
- Jonathan Minond
- CC.Net build reports by email
- Rainbow.Tests run intrusing into CC.Net build script
- Creating a branch for Jon. With his changes he had intrused into MGF's trunk..
Any feedback is welcome
Dear friends, please be attentive on your svn commit actions.
Be sure that your commit will go to the right sandbox repository.
We had a problem with it lately, so I have to afford some recommendations.
Details are in the forum here
Here is the list of issues I am giong to test again and report the nearest time in details.
1. Actual portal is saved in cookies, so it disables cross-portal links.
It requires changes in Global.asax and Rainbow.Settings (Core)
2. If I set UseSingleUserBase=true I cannot edit pages in additional portals even if I am an admin.
It requires changes in core. I am still not have found the full solution...
These revisions are made for finally convert tests of DUEMETRI.UI.WebControls. The commits impact my sandbox only, but these changes to bу merged with Jminold's sandbox and afterwards to main trunk
IMPORTANT! The most affecting change is that DUEMETRI.UI.WebControls.csproj project was renamed to DektopPanesTest.csproj to unify and make convenient DUEMETRI.UI.WebControls solution. It affects the root solution file. I think of moving gathering all those projects to single folder and/or possibly merge projects and their tests. Note that neither output location nor output assemly file name was NOT changed.
For that purposes the DUEMETRI.UI.WebControls solution was created. It contains DUEMETRI.UI.WebControls.DesktopPanes and DUEMETRI.UI.WebControls.HWMenu projects and their corresponding test projects. These tests are not unit tests or other automated tests. They are just for manual testing corrsponing WebControls features. IMO these test projects also could be used as usage examples and features demo for that WebControls.
Existing core unit tests was not converted for new jminold's solutions structure. (Tests.Rainbow.Settings project)
I have already converted them (to project Rainbow.Framework.Core.Tests, you can already see it in my sandbox at revision 131)
They are as many as 2 Fixtures / 4 Test cases.
I am going to merge & intruse them into jminolds new code today...
As to module unit tests, they make sense.
I will think of them after I implement multiportal that is highest priority for me. Do we have other people in our team, that position theirselves as unit tests specialists? We could discuss details of their implementation.
Sttarting from now all SVN documentation related will be supported on the confluence by the link http://support.rainbowportal.net/confluence/display/DOX/SVN
Innovations and urgents will be posted to maillist and possibly to blog or forum (like this message)
To be wide awake you can watch changes using confluence subscription & rss feeds.
Https protocol does not require constantly enter password, but provides enough security. Also, it is noticable faster.
To you will need to run the svn switch command on any of your current local repositories to point them to the new server. For example: svn switch -- relocate svn+ssh://$USER_NAME@forgesvn1.novell.com/svn/rainbow/$PATH
https://forgesvn2.novell.com/svn/rainbow/$PATH
- $USER_NAME is your username that you checked out your code with
- $PATH the the path that you checked out from subversion. It might be something like sandboxes/$USER_NAME or RainbowDotNet2/devint
Also, you can view the repository with your browser by the link https://forgesvn2.novell.com/viewsvn/rainbow/