airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shahbaz Memon <>
Subject GFac code restructuring
Date Mon, 05 May 2014 10:49:06 GMT
Dear all,

Thanks for making the current code structure more reusable and extensible.

Some minor comments on it,

For the monitoring code, I think it is more clean to put monitoring core classes in a separate
gfac-monitor-core or merge it in gfac core. By following this design, we see each provider's
monitoring extension inside its own implementation, such as for gfac-gsissh may contain all
the qstat monitoring classes. This design will help other provider contributors to introduce
monitoring code without touching the fundamental classes of the monitoring api. Furthermore,
the pull monitor extensions or API should be free from any side effects of the monitoring
data structure.

There is a BES provider requirement that it may need to invoke GramDirectory and Gridftp handlers.
If that is so, then according to the current source structure the gfac-bes project is required
to import gfac-gram as a dependency. I am stating this fact here so that the developers can
predict a scenario in which X provider may need to invoke the (data) handlers from Y provider.
Alternatively, the API may also restrict that the provider X should provide its own handlers
if they are not included in gfac-core.

Concerning the assembly of the distribution <modules/distribution..>, the current process
require developers to manually specify the project and its dependency under the assembly descriptor
file. Considering the fact that developer who is building the project, had invested his enough
valuable time in crafting the project poms and dependencies during the early development phase
would not be comfortable to go through the manual dependency resolution process again. In
order to avoid the situation, my proposal is, the dependencies should not be exposed  during
the assembly time, and rather we adapt an automated mechanism in which pom dependencies are
taken from the (declared) modules of interest. In this way we can avoid lot of confusion and
reduce project build lifecycle.

Thanks and Best Regards,


Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt

View raw message