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.