Kepler

Retarget to 2.3, this is now manifesting when changing from reporting to kepler after Jing's change to include a workflow scheduler gui property (which does have an originModule property) in gui's configuration.

Ok, what's happening is reporting and workflow-run-manager override some properties in gui and common's configuration. When you override a property it doesn't get the originModule subproperty. If these configs get written to disk, and you switch back to e.g. vanilla, you'll get errors on startup. I believe this is a shortcoming with our current system. I'm not sure the solution...should overridden properties be written out along side the originals with an originModule subproperty, and we change the ConfigManager to choose the appropriate property based on what modules are active? This doesn't seems especially appealing or easy.

Most of the properties reporting and wrm override could actually instead be simply added with addProperty, thus getting originModule subproperties and avoiding the problem -- but unfortunately we have at least one that I think needs to be a true override, wrm's <viewPaneTabPanes><viewPane>Workflow.

We could possibly punt by putting the two new workflow-scheduler-gui properties in workflow-scheduler-gui's configuration (these are the only 2 properties in a soon to be published module that cause the problem that I know of -- but Dan may need to chime in wrt fault-tolerance), but I'd have to discuss that with Jing. We decided where he currently has them seems like the best place.

For workflow-scheduler-gui module, i changed to use overwrite approach adding the preference tabs. This approach wouldn't serialize the configure.xml on the gui module.

Discussed w/ Jing and Dan.
Can now be retargeted to 2.4.0.

Original Bugzilla ID was 5290