adding and removing configuration properties could be made easier
Now that we've shipped 2.0, if a developer wants to add a new configuration property to a config file, they must first check if the user's config file has the property before accessing it, and add it if not. This is a minor hassle if your code tries to use this property in a number of places, each of which might be reached first during the user's kepler session...you have to do the check and possible add at each place. Instead, maybe the configuration manager could, during startup, run through all active modules config files and add properties if necessary to the user's copies in KeplerData. Handing removing properties would be harder -- if we remove a property, and then a user reverts to an older version of Kepler, this CM method would have to know to add the property back for that version.
#2 Updated by Jing Tao about 9 years ago
In order to make workflow scheduler work, we added a new path -authorization path into the repository. This needs user to remove the old configuration.xml under KeplerData/modules/configruation first.
It is not going to work for regular users. We should automate a way to do this.
#3 Updated by David Welker about 9 years ago
I have made changes to the configuration manager, so that any completely new configuration that is in the active modules but not in KeplerData is added to KeplerData. This will allow developers to add entirely new configuration even if that configuration is not present in KeplerData.
There are limitations that should be noted however. First and foremost, if what one wants to add is not entirely new configuration, but another configuration item to a list of configuration items, this is not currently possible.
Looking into solutions that are more robust and allow adding new items...
#4 Updated by David Welker about 9 years ago
I have added the ability to make what I call add directives. For example, in a module, if you add a new folder called "configuration-directives" and a file called "add.xml" in a module, you will have created a configuration directive for the default "configuraion.xml" file for that module. If you would like to make an add directive for a different file, say "myconfig.xml", you would change the name of the add directive file by simply appending -add.xml to the file name. So, add directive for "myconfig.xml" would go in a file called "myconfig-add.xml."
The contents of add directives can either be simple or complex or a combination of both. For example, a configuration directive may simply make simple additions:
In this example, this add directive specifies that the simply properties property1 and property2 should be added to configuration.xml.
A complex example is as follows:
In this example, this add directive specifies that this complex property with three parts should be added to configuration.xml.
At this stage, I have decided not to add remove or change directives, as further discussion is necessary regarding whether such directives are desirable, and if so, how they should work.
Closing this bug.
#5 Updated by Derik Barseghian almost 9 years ago
I'm reopening this -- now that this directive solution has been implemented, someone needs to utilize it to update the user's config files for any changes we've made. I see there's only an 'add directive' currently-- hopefully no one has removed any properties (i don't know offhand). Diff'ing a 2.0 and 2.1 user's KeplerData config files with those in the release might be one way to try to track these down...
#8 Updated by Derik Barseghian over 8 years ago
The hack included at r26897 to move old configuration xml files out of the way for the first launch of kepler-2.2.0 is not going to help a user moving from any pre-2.2 kepler to any release that's not kepler-2.2.0, e.g. the upcoming kepler-2.3.0 or reporting-2.3.0.
#9 Updated by Derik Barseghian over 8 years ago
Two more issues:
1) if you start kepler-2.2.0 for the first time, your File menu will have 1 Open... option (can open .moml, .kar, .xml). If you move to reporting-2.1.0, you have Open..., Open MoML..., Open MoML URL..., as it is at this version. However when you move back to 2.2.0, the 2 MoML menu items incorrectly remain. This is because tagging adds a menu item, which causes uiMenuMappings_en_US.xml to serialize to disk, and 2.2.0 lacks code to remove the extra MoML items.
The tagging menu item doesn't show up in 2.2.0, but this is more by 'luck'-- the MenuMapper.getActionFor can't create an Action for the missing org.kepler.tagging.TagManagerAction and so it fails to get added.
2) There were some changes to how the tagging menu item gets added post reporting-2.1.0. So in post reporting-2.1.0 the item gets added to the uiMenuMappings_en_US.xml on every startup. This doesn't cause an error per say, but the xml file grows with duplicate entries. The sensor-view suite has a similar problem with menu items it adds.
#10 Updated by Derik Barseghian over 8 years ago
At r27977 and 27978, I checked in a stopgap to this bug -- now configuration xml files are stored in version specific configuration directories. This is not ideal in that a user's settings will not 'carry over' when moving between versions, but something had to be done, and currently we don't have many user settings.