Bug #4516


Module Manager needs ability to install modules needed by KARs

Added by Chad Berkley about 14 years ago. Updated over 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


The roadmap specifies that the module manager should be able to automatically install modules needed by a specific KAR file.

To close this bug, demonstrate that the module manager can automatically install a module needed by a kar file at runtime.

Related issues

Blocked by Kepler - Bug #4483: Module dependencies in MoML filesResolvedDavid Welker10/21/2009

Blocked by Kepler - Bug #4317: KAR's dependencies on modules need to be included in KAR metadataResolvedAaron Aaron08/14/2009

Blocked by Kepler - Bug #5668: module manager should support batch mode execution.ResolvedDaniel Crawl08/07/2012

Actions #1

Updated by Chad Berkley almost 14 years ago

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.

Actions #2

Updated by Chad Berkley almost 14 years ago

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.

Actions #3

Updated by Chad Berkley almost 14 years ago

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.

Actions #4

Updated by Chad Berkley almost 14 years ago

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.

Actions #5

Updated by David Welker almost 14 years ago

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.

Actions #6

Updated by Chad Berkley almost 14 years ago

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.

Actions #7

Updated by Aaron Aaron almost 14 years ago

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.

Actions #8

Updated by Chad Berkley almost 14 years ago

tagged my current work here: Now changing to use the dependsOnModule attribute.

Actions #9

Updated by Chad Berkley almost 14 years ago

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.

Actions #10

Updated by Chad Berkley almost 14 years ago

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.

Actions #11

Updated by Derik Barseghian almost 13 years ago

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.

Actions #12

Updated by Matt Jones over 12 years ago

Moving to 2.3 for target.

Actions #13

Updated by jianwu jianwu over 11 years ago

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 to interact with users. After having this command, we can think how to integrate it with so users will be promoted with missing modules WARNING message and can interact to install those modules.

Postpone it to Kepler 2.5.

Actions #14

Updated by jianwu jianwu over 11 years ago

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

Actions #15

Updated by Redmine Admin over 10 years ago

Original Bugzilla ID was 4516

Actions #16

Updated by Daniel Crawl over 8 years ago

  • Assignee changed from jianwu jianwu to Daniel Crawl
Actions #17

Updated by Daniel Crawl over 8 years ago

  • Status changed from In Progress to Resolved
  • Priority changed from Immediate to Normal

The module manager can now change suites and install patches from the command line.


Also available in: Atom PDF