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

• Before all an analysis requirement has to be changed from "If there are plugin dependencies which are needed for enabling the plugin and they are installed, they also become enabled after the restart." to "If there are plugin dependencies which are needed for enabling the plugin, the plugin can't be enabled. The user must be informed with dialog about that."

• The implementation has to be separated to Fake and True enable/disable of the plugins. First I'll note the things that are the same for both:
  • Module Info class has to be created. It is immutable and consist of the following fields:
    • module id - the module identificator in format 'org.sophie2.*'
    • module activator - this is the bundle-activator under felix. It is SophieModule class name.
    • module description - information about description of the module. This is the <description> tag in the pom.xml of the module.
    • module name - information about module name. This is the <name> tag in the pom.xml of the module.
  • In the ModuleRegistry class the following methods and properties have to be added(and implemented in the fake/true registries of course):
    • ListProp<ModuleInfo> knownModules() - Gets the list of the so-called "known" modules. These are the modules, which have constructed, but are not started yet. In True(in Felix) they are called 'installed modules'.
      • The known modules are gathered from the modules directory in the file system. For this FileEntryManager can be used - it has private method findModulesDir - it can be made protected and can be used.
    • ListProp<ModuleInfo> startedModules() - Gets the list of currently started modules. These are the modules which are already running. Under True(in Felix) they are called active modules.
    • boolean isEnabled(String moduleId) - Checks the module with this given module id is enabled and must return true if the module is enabled.
    • void setEnabled(String moduleId) - Sets the module with the given id to be enabled.
    • void setDisabled(String moduleId) - Sets the module with the given id to be disabled.
    • List<String> getDependencies(String moduleId) - Gets a list of dependencies of the module with the given module id. String element of the list represents the module id of the dependency.
      • the method should gather the dependencies of the modules from the MANIFEST in the jar(Import Packages). Use FileEntryManager to get the file as a resource and parse it(compare the results with known modules so that there is no wrong names for the modules when manifest is parsed - this is because the manifest keeps the packages not only the modules names as Import-Packages.).
  • The following methods has to be removed as long as their functionality is not needed or it will be provided by the upper ones:
    • registeredModules() in FakeModuleRegistry
    • activeModules() in ModuleRegistry

• Implementation under FAKE launch will follow these steps:
  • The fake launch will use author/reader.bundles.config file as True. There will be listed the modules ids of the modules which are enabled and have to be started.
  • start() method in FakeModuleRegistry will start the modules from the config file after their dependencies are being checked. This has to be done with getDependencies and setEnabled/Disabled methods - setEnabled/Disabled will compare the dependencies with the modules from the config and if there are conflicts(the dependency will not be started or the module to be disabled is wanted by some other module) will return false.

• Implementation under TRUE launch will follow these steps:
  • In Main class of the org.sophie2.launcher module AUTO_START_PROP should be changed to AUTO_INSTALL_PROP so all the modules will be started as installed.
  • Only org.sophie2.core and org.sophie2.core.modularity have to be loaded as started modules by Felix.
  • All the others modules should be started in core.modularity using the TrueModuleRegistry and the bundle context(all the bundles can be accessed by it and you can start(), stop() them).

• In func.config module, in PluginAboutPalette add two buttons with label "enable" and "disable" and implement their functionality(they will envoke the setEnabled/Disabled method in FakeModuleRegistry)

• The getDescription() methods of the modules have to be rewritten to give more information and be more clear to the user.
  • Discuss with QA about this.

• The task about support lib alternatives was listed in this group because it is already implemented for the release pre alpha 5 and here will be described:
  • The extensions have its defined sort key(definition can be through the @VisualElementDef annotation or when adding the sophie extension to the list in defineExtension methods. It is generated using three letters, dashes and key word, which describes the extension, for example 'mmm-quick-search-panel' or 'kkk-zoom-percentage-panel'. All extension must have a sort key.
  • A getSorter() method is created - it takes care of sorting the extensions which will be registered and is defined in SophieExtensionPoint so you can override it and define a sorter of the extensions. Now it is implemented for the VisualPoint and compares the keys as strings.
  • The sort keys has to be reconsidered and if there are no such or ones with errors they have to be corrected.

Tests: [2985]

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