airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: GFac code restructuring
Date Tue, 06 May 2014 13:12:48 GMT
Thanks for the feedback, Shahbaz. Regarding the Maven assembly
suggestion, could you provide a working example?

Thanks--

Marlon

On 5/5/14 6:49 AM, Shahbaz Memon wrote:
> 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,
>
> Shahbaz
>
>
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
> 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
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
>
>


Mime
View raw message