Kepler

I added a karEntryHandler for modules.txt files. I'm going to add a method to the module manager sot hat the entryHandler can call it to ask if a module listed in the modules.txt file is installed or not. If it is not, it will install it.

I've now split the module manager into two modules. module-manager now has basic classes for downloading modules. module-manager-gui has all of the gui classes. Just need to hook up the karhandler to the module manager.

Kar files can now include a modules.txt file which will be processed by the ModuleDownloader. Any modules/suites in the modules.txt file wil be downloaded (but not change-to'd). Now need to add code to add downloaded modules into the current modules.txt so that the contents are available to the kar file on the classpath.

The active modules.txt file is now appended with any information from the kar's modules.txt file. Note that this could be dangerous, so we'll need to keep an eye on any kars in the core build of kepler to make sure they're doing this correctly (if at all).

The only other issues is that kepler needs to be restarted after a kar file with a modules.txt file is inserted into the cache or the new module(s) will not be on the classpath. I'm deferring this until we get a runtime system for loading modules.

Closing this bug.

How does appending modules to modules.txt ensure the same environment that an actor was running in?

This is going to fail in some situations.

Couple more issues here:

• I should have used the MANIFEST/dependsOnModule attribute instead of including a modules.txt file in the kar.

A couple questions arise from this:

1) Right now, the infrastructure to download a module tied to a kar file is dependent upon the GUI. Do we want this feature tied to the GUI or not? The way I have it written now, the downloading happens automatically when a kar file is cached with no user input. This puts the burden on the developer of the kar to list a module dependency in an intelligent way. This could cause problems with users who are unfamiliar with the kars that they have downloaded or if the developer unknowingly lists a module that will conflict with another.

2) What about command line execution? Do we want our kars to be able to automatically get dependent modules when kepler is run from the command line?

3) this feature is in the roadmap. Given the problems with potentially corrupting a user's environment, should we reconsider this functionality until kepler 2.0 is more mature?

For now, I will change this to use the existing infrastructure and we can discuss these issues on the next conf. call.

There should always be user input when downloading new modules. Imagine that you are running the Kepler suite, then you download a KAR that depends on the WRP suite modules. Now all of a sudden your desktop app has all this new stuff that you've never seen before, it runs slower, and you have no idea how it got there! The user should always be asked if they want to download new modules when a module dependency is not satisfied.

In a server environment perhaps you would want to automatically download modules. Having a configuration parameter that toggles automatic module downloading on and off could be a way to handle this. I would recommend the default value for that parameter be false though. The user should know what they are getting themselves into by setting it to true.

tagged my current work here: https://code.kepler-project.org/code/kepler/tags/berkley-20100108-checkpoint-kar_can_download_modules-tag/. Now changing to use the dependsOnModule attribute.

I changed this around a bunch so it is now done in the GUI instead of on kepler startup. When a module-dependencies: attribute exists in the MANIFEST for the kar, the icon is changed in the tree and a new rt. click menu is added called "Download Dependencies." When this menu is activated by the user, he is prompted to download the module(s) listed in the MANIFEST. When he clicks "yes" the modules are downloaded. This part is complete.

The only part left to do is to notify the Library that the dependency has been satisfied. Aaron is going to add the code for that, then my code can call it.

Since 4483 is pushed to 2.x, pushing this one as well. most of the functionality is there, we just need a bit more time to implement the underlying code.

I did work on this for bug#5099 . Attempting to open a kar with unsatisfied mod deps now prompts the user to download and restart using the missing modules. Also there's a kar opening strictness setting in preferences that the user can change.
The topic of what to do for headless executions, discussed above, remains open.

Moving to 2.3 for target.

My current tests are still the same. With GUI, Kepler in trunk can identify missing modules and download needed modules through user interaction. In command line, it will show WARNING message about missing modules and can execute with '-force' option.

In many cases, users use command line because they cannot open a GUI, such as when running Kepler on a remote machine. So ideally, users should be able to install missing modules only via command line interaction, like install some linux packages. It means we need a command like keplerModuleManager.sh to interact with users. After having this command, we can think how to integrate it with kepler.sh so users will be promoted with missing modules WARNING message and can interact to install those modules.

Postpone it to Kepler 2.5.

It is related to bug 5495 since both need module manager interaction through command line.

Original Bugzilla ID was 4516