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 > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > >
