Tentative List of Kepler 2.2 Features

For the most recent list of 2.2.0 features see: Bugzilla: Bugs and Enhancements targeted to 2.2.0. (If you are logged in to Bugzilla, you will see effort estimates).

For the list of 2.3.0 features, see: Bugzilla: Bugs and Enhancements targeted for 2.3.0

Possibly obsolete below here . . .

1. (Bug 5065) (2.2.0) In shared or administrative installations, the ability to store modules.txt and extra modules locally. This way, the module manager will work smoothly on Windows without having to run as an administrator.
2. (Bug 5026) (2.2.0) Error dialog pop up in RC3 when closing the ImageJ window after workflow execution)(P2,2.X.Y) Fix ImageJ so that preferences are stored in an area other than the installation space. This may require a change to ImageJ source code.
3. (Bug 5067) (2.X.Y) The introduction of basic services so that module names are not referenced.
4. (Bug 5068) (2.X.Y) Investigating and upgrading jars.
   
5. (Bug 5069) (2.X.Y) The ability to create user manuals from a wiki that is continuously updated.
6. (Bug 5070) (2.X.Y) Changing the "Available Modules" tab in the Module Manager to "Available Suites and Modules"
7. (Bug 5071) (2.3.0 or 2.2.0) Improve the installer so that it is automated instead of requiring so many manual steps.
8. (Bug 5072) (2.3.0 or 2.2.0) Move the R module out of Kepler/CORE entirely. Set up the module manager to handle the R installation process when a suite including the R module is downloaded without requiring the user to handle installation manually. Move getting-started workflows that use the R actor out of Kepler/CORE into the r module.
9. (Bug 5073) (2.2.0) In module manager, display the current suite name.
10. (Bug 5074) (2.2.0) Fix the release process so that modules can be released on Windows machines.
11. (Bug 5075) (2.2.0) Fix the module manager so it can show docs with any name.
12. (Bug 5076) (2.X.Y) Minimize the number of files downloaded from the Ptolemy repository.
13. (Bug 5084) (2.2.0) Allow test releases in the same location as actual release.
    
14. (Bug 5089) (2.2.0) Replace operating system specific files with operating system specific modules.

Analysis

(1) In shared or administrative installations, the ability to store modules.txt and extra modules locally. This way, the module manager will work smoothly on Windows without having to run as an administrator.

Problem: The file modules.txt is read by Kepler to determine which modules are active. Both modules.txt and local modules are currently stored in the installation area, which in shared installations is read-only. Because extra modules are executed, security might dictate that in shared installation situations modules.txt not be changed and new modules not be downloaded. This was the original rationale for going forward with our current design However, on Windows, the default for installations appears to be to install as an administrator. As a result, even in private non-shared installations on Windows, it can be difficult to use the Module Manager. To do so, a user must remember to run as an administrator, which gives Kepler the ability to write to the installation area.

Solution 1: Store modules.txt and download new modules not to the installation area, but to a designated location in the users home where write access will be available. The downside of this approach is that this would decrease the security of truly shared installations of Kepler. On the other hand, a problem with malicious modules may be more theoretical than real at this point, as modules are now published and retrieved from a centralized source that we control. Also, if there is a problem with malicious modules, it would affect not just shared installations, but individual installations; protecting shared installations does nothing to protect individual installations which are perhaps just as important. Also, the real risk of malicious modules is low, given current development patterns.

Solution 2: Try to find a way so that Windows installations are not done by default on Windows. This may or may not be possible.

Solution 3: Warn users who do not have appropriate write permissions to the installation area that they may not use the Module Manager. The design of such a warning should be thought through so that it is non-intrusive and graceful. For example, it probably should not pop-up at start-up, but only when the user attempts to invoke Module Manager functionality.

Conclusion: At the very least, users who cannot use the Module Manager due to lack of permission to write to where Kepler has been installed should be warned. Perhaps even better, given the prevalence of this problem in Windows and relatively low security risks, modules.txt and new module downloads should occur in a local area that is writable.

(2) Fix for ImageJ so that preferences are stored in an area other than the installation space. This may require a change to ImageJ source code.

The issue here is that the preferences are saved relative to the ImageJ jar file, and the jar file is often stored in a real-only area. Solving problem (1) will not solve this problem. A good solution if (1) is solved by downloading added modules in a local area would be to perhaps isolate ImageJ to its own module. Alternatively, the code of ImageJ could be changed to handle saving preferences differently, but this would cause maintenance issues.

(3) The introduction of basic services so that module names are not referenced.

Modules would just declare that they provide a service and this would have a meaning that is understandable to humans. Services should be used to provide properties and also resources, so that module names are not referenced in code. Also, a workflow could declare that it requires certain services and detect if the modules present do not provide those services and in that case provide an appropriate message to the users. The most difficult issue with services is whether they should be versioned and if so, how?

(4) Investigate jars (why they are necessary) and upgrade whenever possible.

It is better for us to make the latest jars available, so that Kepler developers can easily use the latest functionality. The assumption is that later versions are usually better than older versions. Also, we should have a better understanding of the interrelationship between jars and code.

(5) The ability to create user manuals from a wiki that is continuously updated.

Currently, our user manual is produced from a document in the Microsoft Word document. This makes it inconvenient to update a version of the manual that reflects the most recent versions. As a result, the manual tends to be updated all at once during a release and probably is not as good as it could otherwise be. Also, being able to read the manual off the web and not just in PDF format would be very convenient for users as well.

(6) Changing the "Available Modules" tab in the Module Manager to "Available Suites and Modules"

This is a minor change that could be made to make the GUI more clear.

(7) Improve the installer so that it is automated instead of requiring so many manual steps. Also, develop streamlined release process so that minor releases 2.1, 2.2, etc. can be accomplished more rapidly.

This is critical if we want to make more frequent releases. Also, application wide resources that need to be updated with every incremental release should be stored in one module. An ideal candidate would be the Kepler suite module. That way, if a patch occurs, the splash screen and other resources can all easily be updated to reflect the patch. The splash screen should not longer be done in photoshop, but instead a method should be devised such that text indicating the version number is somehow merged with a background image.

(8) Move the R module out of Kepler/CORE entirely. Set up the module manager to handle the R installation process when a suite including the R module is downloaded without requiring the user to handle installation manually. Move getting-started workflows that use the R actor out of Kepler/CORE into the r module.

The R module does not add anything to Kepler unless R is installed. Also, often the exact version of R that is required matters. A mini-installer would be able to ensure that the user downloads a compatible version of R for use with Kepler.

(9) In module manager, display the current suite name as well as a fully resolved list of modules.

The module manager currently displays the content of modules.txt. If modules.txt refers to other suites, it is not possible to tell what modules are actually in use. Also, it is not possible to tell what the current suite (if it is non-custom) is currently selected. The module manager display would be more useful if it displayed this information.

(10) Fix the release process so modules can be released from Windows machines.

Currently, the release process often fails when attempted from Windows. This may or may not be fixable; I suspect that this is due to limitations in the SVN client on Windows. However, this problem should be investigated and fixed if possible.

(11) Fix the module manager so it can show docs with any name.

Currently, the module manager only displays documents named in a certain way. Instead, it should show every document in a given folder. This would allow multiple documents to be associated with a module and for more descriptive names to be selected for documents available from the module manager.

(12) Minimize the number of files downloaded from the Ptolemy repository.

Ptolemy is a very large project that consists of a large number of files. Many of these files are not useful to Kepler, but they nonetheless significantly slow down Eclipse and IDEA. It should be possible to design the build system so that it does not download a majority of the files that are not actually useful for Kepler. One approach would be to divide Ptolemy into modules. Another would be to divide the Ptolemy repository into parts and download those parts either into separate modules or one or more special modules.

(13) Allow test releases in the same location as actual releases.

Right now, the Kepler module manager can be configured to look at a test-release location rather than the actual release location. However, this is not necessarily ideal because the resources available in the test-release location may not always be identical to the actual release location, or if it is, this requires maintenance and duplication of resources. A possible solution would be to create a flag of some sort (which might be indicated by the presence of a special file, for example) so that test-modules are not shown in the module manager, unless the user selects an appropriate check box or menu item. In this way, test releases would be guaranteed to have access to the same resources as released modules without cluttering up the module manager.

(14) Replace operating system specific files with operating system specific modules.

Currently, as illustrated by the apple-extensions module, it is possible to specify specific Java files that are not compiled on particular operating systems. So, for example, the files in apple-extensions are only compiled on Mac OS X, but not on Windows or Linux. This is less than an ideal solution however, since IDE's do not naturally know about such files and have to be manually adjusted to have this knowledge. Furthermore, there are other resources besides Java files that are often operating system specific and can be large in size. For example, operating system specific native libraries. A better solution would be to have operating system specific modules that are only retrieved in the first place. In this way, the IDE problem will be solved and further this would reduce unnecessary downloads of large operating system specific files that are not used.