Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_PLUGINS_ENABLE_DISABLE_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

Plugins (or modules) are one of the main important parts which increase sophie platform flexibility and extensibility. The main purpose of this group of tasks is to provide functionality for enabling/disabling sophie modules while the application is running (in this revision the application has to be restarted to enable/disable a plugin). The config plugin palette will be improved to show more information about sophie plugins.

Task requirements

• In the plugin config palette when you click a module name two buttons - 'enable' and 'disable' - has to be shown. Depending on the plugin state one of them should be inactive.
  • When enable/disable option is activated the effect will show after restarting sophie application.
  • If the selected plugin cannot be disabled because some of the plugins depends on it, it can't be disabled. The user has to be informed about this with a dialog.
  • If there are plugin dependencies which are needed for enabling the plugin and they are installed, they also become enabled after the restart.
    • Note: the case when they are not installed should be resolved in the next revision of the task. For now the user will be informed that there are no such dependencies installed to run the plugin he wants.
  • (optional) Make a dialog with yes/no buttons so the user can choose what will be the behaviour when dependencies are shown.(i.e. if the plugin will be enabled with its dependencies or not enabled at all)
• Some of the plugins can't be disabled(i.e. core.modularity or core), so their enable/disable buttons should be always inactive. Think if there is a need to show these plugins on the config palette.
• Internal managing/configuration of the plugins has to be implemented - this is connected with the upper functionality
• Already implemented support of the sorting of plugins has to be reviewed and improved.
• The about information of each plugin has to be updated and rewritten.

Task result

• improved config palette
• source code - tests and implementation

Implementation idea

• Do not forget that there should be fake and true implementations of internal plugin configuration and managing.
• Create new module where plugin manager should be implemented - it will take care of enabling/disabling of the plugins.
• Research OSGI bundles and how to use them for dynamic plugin switching.

Related

GROUP_PLUGINS_R0
APP_PLUGIN_MANAGER_LIST_R0
APP_PLUGIN_MANAGER_CONFIGURE_R0
PLUGIN_SUPPORT_LIB_BASE_R1

How to demo

• Enable a plugin from the palette.
• Restart the application.
• Show that the plugin is running now.
• Repeat the steps using disable option.
• Show that some plugins can't be disabled.

Design

• Use the func.config module to add the functionality which will be implemented in this task.
• The main idea is to create plugin manager which will take care of enabling/disabling plugins when the user wants it. The implementation is separated to Fake and True managing of the plugins:
  • True plugin management which consist of:
    • a configuration files with the modules(two for author and reader) -
      • it will contain the modules names(like author.bundles.config for example) and 'enable' or 'disable' depending on the state they are left after shutting down the application.
    • a plugin manager which read the configuration file and starts the bundles using the system bundle context and bundle start() method.
    • edited launcher Main class - the launcher has to start only core and some of the base bundles which can't be disabled in any case(these that can be disabled are base.halos, base.skins, base.connectivity and base.media).
      • It is not so hard to start only some of the modules - they have to be added as static names in a list before starting the felix instance and they have to be added in the config map as AUTO_START_PROP.
      • All the other bundles have to be started as installed bundles only(or as AUTO_INSTALL_PROP added to the config map in the launcher main class).
  • Fake plugin management which consist of:
    • the same configuration files as in true
    • a class which will start the modules instead of FakeAuthorMain, which has to be refactored to start only the needed core/base modules (again all the core modules and all the base without the upper ones)
      • This has to be something like the launcher main class but, because we don't have the names of the bundle activators and we need them for starting, all pom.xml's have to be parsed to get the bundle activator name.
        • this can be achieved using FileEntryManager to get the resource for parsing

Implementation

^{(Describe and link the implementation results here (from the wiki or the repository).)}

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}