Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_PLUGINS_R0, format=table, col=summary|owner|status|type|component|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

This group of tasks is about providing internal support for plugin configuration that is needed for the release of the pre-alpha-4 version. A library supporting plugin configuration should be written and its use should be demonstrated.

Task requirements

• Provide an API for dealing with shared resources:
  • Resources that will be used by the application should go in the /src/main/resources/distrib folder of each module.
  • Resources used in testing should be in the /src/test/resources/distrib folder of the tested module.
  • Paths containing resources at runtime should also be considered (these are in the target directory).
  • A resource manager should be implemented - it should be able to get these resources.
  • All existing static paths should be changed to use the newly written functionality.
  • Both the Fake and True launchers should correctly handle these.
• Provide an API that allows some kind of plugin configuration:
  • Define how plugins will be configured.
  • Provide the classes/iterfaces necessary for plugin configuration support.
  • Choose a plugin that will be configured and define what will be configured about it. (Optional)
• Add a plugin configuration palette to the application:
  • Make sure it works in the TrueAuthorMain (currently the plugin info palette that exist works in the FakeAuthor only).
  • It should allow configuring of the selected plugin if the plugin supports it.
  • At least one plugin should be configurable at this iteration. (Optional)

Task result

Source code

Implementation idea

• Consider using a config file for each plugin and loading it as a resource.
• See if you can use the OSGi plugin configuration service.
• A plugin might provide a list of all configuration options that can be configured (just a list, no GUI elements).
• Another option is for the plugin to provide the GUI configuration elements - a panel, dialogs or whatever is needed.

Related

PLUGIN_SUPPORT_LIB_BASE_R1
APP_PLUGIN_MANAGER_CONFIGURE_R0

How to demo

• Configure a plugin from the plugin configuration palette. (Optional)
• Show and briefly describe the code of the plugin support library.

Design

The org.sophie2.core.modularity module will be expanded by actually implementing the TrueModuleRegistry and a FileEntryManager. The TrueModuleRegistry will contain a list of the modules started by Felix. Each module will register itself in this list at startup - this will be implemented in the SophieModule class. This class will also provide the abstract methods isConfigurable() and configure() that can be implemented by each module that has some configuration. Each plugin does the configuration on its own and decides how to provide it. The FileEntryManager will contain methods for getting readable and writable resources (file entries). The PluginAboutPallete will be changed so that it takes the current ModuleRegistry as a source (not the Fake one as it was until now). The ModuleRegistry class get() method will return the appropriate registry. The following class diagram reflects the changes that will be made to the core.modularity module:

Two unit tests will be created: TrueModuleRegistryTest and FileEntryManagerTest.

Code using the Class.getResource() method will be refactored to use the FileEntryManager.

Implementation

Done according to the design. Changesets:
1781, 1792, 1794, 1800, 1801, 1802, 1904, 1905, 1906.

Testing

^{Place the testing results here.}

Comments

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