Hanz/reorg repo structure

[hanzzhang]

connect to #147

created folder structure as: •build •docs •setup •src ◦AdhocExploration ◦LongTermStorage ◦Shared ◦Simulator

[VeronicaWasson]

Are we getting rid of the root solution file? That makes it hard to build everything.

[hanzzhang]

Mike, we are getting rid of the root solution file.

[mattjohnsonpint]

Other than the typo, looks good to me. Though I have a couple of questions/comments

• We're using new terms for the top-level folder names that don't match the solution/project/namespace. IMHO these should all be aligned:
  • LongTermStorage vs ColdStorage
  • AdHocExploration vs WarmStorage
  • Simulator vs ScenarioSimulator
• I find it confusing that the config files aren't all at the same depth within their corresponding folders.
  • The cold storage config file in the root, next to the sln file.
  • The warm storage and simulator config files are one level deeper, with the console host .csproj files. They should be brought up one level.
• I'm not sure why the config file names need to be prefixed so verbosely. Example, WarmStorage.EventProcessor.ConsoleHost.Template.config could probably just be settings.template.config (with the real file being settings.config).
• It might be cleaner if the shared packages folder was built at /src/Shared/packages instead of /src/packages.
• Why is is the simulator also not in a "dotnet" folder to match the structure of the other two?

Also, just FYI - after pulling down these changes, one needs to do a git clean -fd with VS closed to clean up the old structure.

[lbrader]

good catches Matt.

On the LongTermStorage VS Coldstorage points. I thought the high level was capturing the scenario story and then we drilled down into technology implementation. So I thought this was OK.

Be interested in what others think on this item.

On the naming for configuration. Totally agree with Matt. Simple simple simple naming convention. Let the location provide the configuration context. More I think about it, I'm all for a single configuration file. This is an Reference Implementation and should be easy to change the configuration. Hunting around to change various settings that really repeated in other files is a pain.

Move packages out of Share. Share should be for the files we produce - not 3rd party packages.

On the Simulator, understand your point. But we have no backlog to move the simulator to other technologies at the moment. Where we do on the other scenario's. My thought is to leave it as it is, until we specifically get direction to consider simulation with other technologies.

mantra - stay simple.