[kepler-dev] [Bug 4483] - Module dependencies in MoML files

bugzilla-daemon at ecoinformatics.org bugzilla-daemon at ecoinformatics.org
Thu Oct 22 12:56:05 PDT 2009


http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4483





------- Comment #7 from welker4kepler at gmail.com  2009-10-22 12:56 -------
Your point about overrides is not correct. If you are using a module that
includes an override and your workflow uses that class, then you know there is
a dependency on the module that contains the override.

However, automatic dependency detection will not work in cases where reflection
is used, unless we develop a specific means of detecting reflection within the
code. Further, even if we solved this reflection problem, we could not detect
module dependencies on modules that contain required non-java third party tools
where the module does not also satisfy any java class dependencies.

I don't think there is any good way to do this automatically. 

Let's just have the default be that all the modules in the active configuration
in which the workflow was developed are required and let the workflow engineer
specify that certain modules aren't in fact required if that is known to the
workflow engineer.

If the workflow engineer developed comprehensive tests, it might be possible to
determine dynamically what modules are really required using a sophisticated
nightly build. But this sort of infrastructure would take time to develop and
would imply a lot more work for workflow developers in developing testing
mechanisms that exercise the workflow in a fairly comprehensive way. Even after
all that, if the tests were not good, this sort of automatic determination
would fail.

Overall, I don't think this is too bad. The worst case scenario is that someone
downloads a module that is not really needed and has to restart Kepler in order
to run the workflow. Most of the time, all of the modules in the current active
configuration in fact will be required. In cases where that is not the case,
inconvenience to the user can be avoided by workflow engineers indicating that
certain dependencies are not in fact required.


More information about the Kepler-dev mailing list