Working with the code

Jan 17, 2011 at 9:08 AM

Just a few questions and thoughts to help us all understand a little better

  • For starters, pulling the code from the repo, vs getting the source zip, why does the repo have all the contrib modules also? (and they seem to be out of date)
  • In 'Orchard.sln' add a few more solution folders for organization. I added something like the following to help me understand:
    • Modules - 0. Core
      • Orchard.Core
    • Modules - 1. Standard
      • Blogs, Comments, ...
    • Modules - 2. Extended
      • Lucene, ArchiveLater, ...
    • Modules - 3. Contrib
      • Chapters, Taxonomies, ...
  • Why do themes have a layout similar to Orchard.Core instead of like the standard modules?
  • version numbers are all out of sync.
  • make Scripting.DLR more easily removable
  • look at adding a 'clean-for-deployment' script (powershell?) I have a 600MB Orchard.Web folder. This is just plain wrong. Whats going to be the long term deployment startegy when not publishing modules to the gallery?
Jan 17, 2011 at 12:12 PM

here are some explanation about why put "core module" in Core.

Jan 17, 2011 at 6:39 PM

Mmmh. What makes you think the modules are out of date? Where are you seeing the contrib modules?

I do not understand the question about layout and Orchard.Core. Can you elaborate?

What version numbers are out of sync? Modules? What branch are you looking at?

How could Scripting.DLR be more easily removable? What happens when you try? What difficulties are you seeing?

We are looking at ways to remove all those duplicate dlls in Orchard.Web for deployment. In the meantime, you can deploy only the copies of dlls that are in the root bin of Orchard.Web. The others are added when compiling from Visual Studio and are not needed.

Jan 18, 2011 at 12:05 AM

I based these comments from the 31172855b8f7 changeset from the source code tab.

When I download the published zip from the downloads, it only includes the "core" and "standard/default" modules. The source from the source tab includes many additional "contrib" modules. Most of which were .8 or .9 release, and none matched the published counterpart on the gallery.

As for the version numbers, almost all projects were still at 0.9.0. I see that there has been a changeset checked in today, so i guess these were found and addressed.

freeflying1222, I totally understand why "core" modules are the way they are. No issue there. You didn't understand what I was asking for. I was asking for more logical partitions within the "Orchard.sln" file. I suggested making additional solution folders for each grouping of module. Obviously the 'core' folder would only have the core project. But I was asking for seperation of what is 'default/standard' versus what was contributed. The issue being that alot of the contrib packages also have their own codeplex projects with generally more up to date source.

As far as Scripting.DLR, it really is all modules that share the same test project that is the issue. You cant easily "remove" from your solution some modules without bringing out the scapel to nuter the tests appropriately. Here I believe that you should have one test project for each independent module.

As far a deployment, it seems after reading other threads, that the only clean supported path at the moment, is to first deploy the base Orchard.Web from the download, and the package up all my modules, then manuall install them into the site. This was not my initial plan of attack, but it could be managable. Ideally I was hoping that a 'package' would only contain the DLL that gets cached in App_Data\Dependencies and the *.cshtml, *.css, and *.js files to be as streamlined as possible. I do understand the value of dynamic compilation, but the notion that this is a good practice in production is not.

Jan 18, 2011 at 12:11 AM

I'm quite puzzled about both the "0.8 or 0.9" claims and your seeing "contrib" modules there that have their own CodePlex projects. Can you give some specific example?

Jan 18, 2011 at 12:34 AM

I think i get what Eddie is saying

1. Removing the Scripting.DLR module from the _source solution_ is difficult today because all of our tests for modules are in a single Unit Test project. We should have 1 unit test project per "non core" module.

2. The default branch was still tagged "0.9" until this morning, I did the merge from 1.x to default and tagged defautl as "1.0". I also updated and checked in the source files (assembly info and module.txt) with the v1 version #: 1.0.20. The version number is always set in the source on our CI server when we create packages, but we didn't check in in the repository.

3. Themes project: it was just for convenience for our "built-in" themes to avoid having too many projects. For creating additional, it is recommended to use distinct projects.

4. Deployment: From the feedback we are getting, it sounds we need to create a new msbuild target or an orchard command to prepare a "local" site for deployment. If you look at "orchard.proj" at the root, you will see the "Package" target which create the "" file. It does almost exactly what you need, except it has some special cases to exclude for "contrib" modules. Or maybe we should just create a new target that "cleans" all the files that are not needed. The fact the site is 500+MB is because Visual Studio build system makes a copy of Orchard.Framework and all the dependencies in the the "bin" folder of all the modules in the solution. That's in addition to the temporary files in "obj", etc. The Visual Studio "Clean Solution" command does clean too many things unfortunately...

5. Concerning the deploy sources or binaries topic, although the scenario you are describing is supported (deploy binaries only), I'm still not quite clear why you think deploying source files in production is a "no-no"? .cshtml files are "source files" too, no?

Jan 18, 2011 at 12:46 AM

Ah, makes sense, thanks.

Jan 18, 2011 at 5:15 AM

As per #5, yes razor files are compiled too. I wasnt thinking about that. I was more thinking along the lines of support senarios at a few places I have worked before. There the production support team was 100% different from the development/maintenance team. Any code that they could change, the did without thinking about its impact. I was more thinking about a 100% compiled release + static resources.