The unicore's project structure is very similar to the airavata server, so as an example let me use unicore build as a reference.
For the build we are using maven-ant-tasks to reference server pom (which includes deps to all the required sub modules only, i.e not to any third party libs). In the airavata's frame of reference it is ..modules/server/pom.xml which will include all the server projects. Here is the sample ant build file that is using the server pom, http://sourceforge.net/p/unicore/svn/HEAD/tree/quickstart/trunk/build.xml The primary goal is to prevent the release manager from modifying the assembly includes each time there is new third party dependency and reduce the overall build cycle. I see this option as more usable, and not burdensome as compare to the assembly descriptor. This approach is just my experience. I have no doubts that there might be more optimal solutions available in the open source world. Thanks, Shahbaz On Tue, May 6, 2014 at 3:12 PM, Marlon Pierce <[email protected]> wrote: > 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 > > > ------------------------------------------------------------------------------------------------ > > > ------------------------------------------------------------------------------------------------ > > > > > >
