Bug #5174
closedReduce the number of modules in Kepler CORE.
0%
Description
The number of modules in Kepler is a little bit overwhelming. If the user was required to specify modules.txt manually (as they would in some rarer use cases) it would be tedious at best. Given that our current module set was not developed according to completely consistent guidelines, we should develop such a set of guidelines with an eye to reducing the number of modules to make manual specification of modules more manageable.
Updated by Christopher Brooks over 13 years ago
My theory about the number of modules is that tool developers want
to have many modules because they see all the combinations and see
them all as useful. Tool users just want one module, because they
see the tool as a monolithic object and don't care if they get
extra stuff.
This is true of Ptolemy, where I see it as many modules and Kepler
developers and users just see it as one module.
One possible solution would be to includes ways to group modules -
a hierarchy of modules. We may even have this now. The idea
is that a product consists of a number of groups of modules or
groups of groups etc. Modules don't necessarily belong to a specific
group, for example the ptolemy.util module is used by both the
headless ptolemy runtime engine and the plotter.
By using groups, it might be possible to help the user decide what
modules are needed.