Kepler

If a new release of a module contains new properties in one of its configuration files, these updates will not appear since the existing configuration file in KeplerData is used.

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.

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...

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:

<config>
<property1>myValue</property1>
<property2>myValue2</property2>
</config>

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:

<config>
<complexProperty>
<name1>myValue</name1>
<name2>myValue2</name2>
<name3>myValue3</name3>
</complexProperty>
</config>

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.

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...

I have sent an email to kepler-dev to get responses from people who have made configuration changes since Kepler 2.1. For people who respond, I will put their name and their changes in this bug.

This enhancement needs to accommodate not just addition, but changes and deletions as well. All that has been implemented to this point are additions. Changes and deletions will be addressed sometime post 2.2, probably in 2.3.

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.

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.

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.

Original Bugzilla ID was 5129