[kepler-dev] Questions/Thoughts on the modular system

[Chad Berkley]

Hey Ilkay,

You can see the dependencies in the module-info/modules.txt file of the 
suite or module that you're running.  modules.txt lists the compilation 
dependency order from the top down.  It does not handle jar 
dependencies, however.

As for conflicts, there isn't really a way right now to tell if there 
would be a conflict between two modules.  You can see the overrides of 
any module with the 'ant report-all-overrides' which would give you a 
good idea about whether two modules override the same file.  I know 
that's not a very good way to find conflicts, but I thought I'd just 
point out that it does exist.

Right now the module-manager allows you to load new modules into kepler 
at runtime.  I haven't played with it in a while, but it did require a 
kepler restart to take effect the last time I tried it.

I agree with Matt about putting jars into modules themselves.  I think 
that would be the best way to control their versions right now.

chad


Matt Jones wrote:
> Hi Ilkay,
> 
> Good questions.... my perspective below....
> 
> On Fri, Aug 21, 2009 at 12:31 PM, Ilkay Altintas<altintas at sdsc.edu> wrote:
>> The new modular system mostly works great and I like the new organization of
>> files.
>> I have a few questions/comments below on capabilities that I think are key
>> to the broad usability of it.
>> 1. Module dependencies/conflicts: How do I know different modules depend on
>> each other or would conflict with each other? Do we expect the users to
>> download any module and add it into their build? We need documentation with
>> each module on what are the pre-conditions for using that module: an example
>> configuration for the module, list of what other modules NOT to use it with,
>> and what is required with this module. We need to define standards for
>> publishing a module.
> I agree we need these dependencies to be explicit and trackable.
> 
>> 2. Module manager: I understand there will be a visual module manager for
>> this. Will the manager take care of some of the issues?
> yes, I think module-manager will be the approach here.
> 
>> 3. Jar conflicts: If two modules need different versions of the same jar, it
>> will not cause compile errors. However, it could end up causing jar
>> conflicts at runtime. How do we deal with this problem? What's going to
>> happen when third parties start publishing modules?
> I think jar files (or small related collections of jar files) should
> often be published as their own modules to facilitate much mroe
> explicit dependency checking on jars.  Without it, these incidental
> jar overrides are indeed a problem.
> 
> Matt
> 
>> Thank you and apologies if some of these were discussed before.
>> -ilkay
>>
>> --
>> Ilkay ALTINTAS
>> Deputy Coordinator for Research, San Diego Supercomputer Center (SDSC)
>> Lab Director, Scientific Workflow Automation Technologies (SWAT @ SDSC)
>>
>> University of California, San Diego
>> 9500 Gilman Drive, MC: 0505  La Jolla, CA  92093-0505
>> Phone: (858) 210-5877                     Fax: (858) 534-8303
>> Web: http://users.sdsc.edu/~altintas
>> Skype: ilkay.altintas
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>>
> 
> 
>