wiki:GROUP_PLUGINS_ENABLE_DISABLE_R0
Last modified 16 years ago Last modified on 07/23/09 17:16:00

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

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:
      • String module id - the module identificator in format 'org.sophie2.*'
      • Class<? extends SophieModule> module activator - this is the bundle-activator under felix. It is SophieModule class name.
      • String module description - information about description of the module. This is the <description> tag in the pom.xml of the module.
      • String module name - information about module name. This is the <name> tag in the pom.xml of the module.
      • List<String> moduleDependencies - information about module dependencies. The method should gather the dependencies of the modules from the pom.xml in the jar or in the modules/moduleName. Use FileEntryManager to get the file as a resource and parse it.
    • 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 - helper method for finding the pom.xml path has to be created and findModulesDir has to be made protected.
      • 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.
      • boolean setEnabled(String moduleId) - Sets the module with the given id to be enabled.
      • boolean setDisabled(String moduleId) - Sets the module with the given id to be disabled.
        • 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.
        • Note: for the other revision parsing of the MANIFEST should be provided ( then you should 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.
  • 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). There will be listed the known modules and after each of them there has to be a status if it is running or not. This information is gathered from the bundles config file.

  • 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], [2993]

Commited to the trunk: [3042].

Implementation

Diffs from the design:

  • Fake module registry implementation was not done because of the low priority of working config palette under fake launch.
  • The started modules are started in Main not in TrueModuleRegistry. They are loaded in the config felix map.
  • Flags 'started' or 'stopped' are added in the config files - they show if particular module has to be started or not started when felix is launching. The config files are moved in the org.sophie2.launcher module in the resources.
  • ModuleInfo class is created - there all the pom.xml files(get from FileEntryManager findPomFromUrl() newly implemented method) are parsed and the information about each module is extracted (name, moduleId, description, dependencies, moduleUrl, activator).
  • In TrueModuleRegistry the following methods are added:
    • constructKnownModules - fills the known modules list property when initializing the TrueModuleRegistry, which are all the sophie modules (all modules in the bundles file),
    • constructFileLines - reads from the config file and parses its lines, fills the configFileLines property, which helps in the implementation of startedModules, setEnabled and setDisabled methods. Again called during the TrueModuleRegistry initialization.
    • isEnabled(moduleId) - checks if module with this moduleId is already enabled.
  • File entry manager is refactored, a lot of ugly things are removed but some of them stay for now.. Their cleaning will be part of the deployment task.
    • system property is added - sophie2.development - it is true if sophie2 is launched through true or fake launchers but under Eclipse, false otherwise. It is set in the launcher and is very clever Vlado's idea.

One of the known bugs here is that the buttons are not with LogicR3 because of the very slow implementation of the task and are very ugly. I'm not going to fix them now because this is already part of the UI refactoring:).

Other interesting bug is that file entry manager creates two distrib directories in the launcher module for the logger. Will be fixed in the group deployment.

Revisions: [2993], [3646], [2648], [4236], [4272], [4353], [4354], [4356], [4400] (only fix here and trunk merging it's my fault), [4466]

Note: the review of this implementation must be done in parallel with java web start because of the file entry manager fixing that is not working with only one of the tasks.. so in the revisions there are fixes about java web start too.

Testing

(Place the testing results here.)

Comments

(Write comments for this or later revisions here.)