airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shameera Rathnayaka <shameerai...@gmail.com>
Subject Re: Too Many Leaf Modules.
Date Fri, 29 May 2015 15:02:49 GMT
Hi Supun,

Gfac can be expand more with project future plans, support web service ,
cloud job submission, in that case I think it is better to keep it
separately. Initially I thought to merge orchestrator to service module
despite of having separate module. But with the feature in the road map
like meta scheduling features can put to this orchestrator module. service
module will have all core implementations like thrift services including
Gfac core implementation. I think it is better to keep core with all
interfaces and basic classes and it should decouple from other modules.


Thanks,
Shameera.

On Fri, May 29, 2015 at 10:24 AM, Supun Kamburugamuve <supun06@gmail.com>
wrote:

> I guess you can put service, orchestrator and gfac in to core as well.
>
> Thanks,
> Supun..
>
> On Fri, May 29, 2015 at 10:15 AM, Shameera Rathnayaka <shameera@apache.org
> > wrote:
>
>> Hi Devs,
>>
>> As we are using different modules to package different type of
>> functionalities, which will help us to maintain loosely couple codes. Now
>> the project has 49 leaf module ( one to hit half century :) ). If we allow
>> project to grow this way, having too fine grain modules will be huge
>> headache in future. IMO we should clean this ASAP before it become really
>> mess. Actually we half way there, I experienced cyclic dependency issues
>> when I was writing workflow implementation and email monitoring. Please see
>> the modules in current repo below.
>>
>> <module-name> ( <num of child modules> )
>>
>> modules  ( 43 )
>>      app-catalog ( 2 )
>>      commons ( 1 )
>>      configurations ( 2 )
>>      credential-store ( 3 )
>>      distribution ( 8 )
>>      gfac ( 10 )
>>      integration test ( 1 )
>>      messaging ( 2 )
>>      orchestrator ( 3 )
>>      registry ( 3 )
>>      security ( 1 )
>>      server ( 1 )
>>      test-suit ( 1 )
>>      workflow ( 1 )
>>      workflow-modal ( 3 )
>>      xbaya ( 1 )
>> airavata-api ( 5 )
>> tools ( 1 )
>>
>> Most of the current modules have interfaces and implementations together,
>> but this violate our main goal which reduce inter module dependencies.
>> Following is what I am suggesting, WDYS?
>>
>> core { has all core interfaces and basic classes of gfac-core ,
>> orchestrator-core , message-core , monitor core, registry core,
>> workflow-core}
>> service - all thrift services and service handlers
>> orchestrator - orchestrator specific classes
>> gfac
>>      SSH
>>      BES
>>      Local
>> message - amqp implemention
>> distribution
>>      XBaya
>>      server - { use different mode input to start server as orchestrator
>> , Gfac or/and api-server }
>> commons
>> registry
>> app-catalog
>> security
>> Workflow
>> XBaya-gui
>> Integration-test
>>
>> Thanks,
>> Shameera.
>>
>
>
>
> --
> Supun Kamburugamuva
> Member, Apache Software Foundation; http://www.apache.org
> E-mail: supun06@gmail.com;  Mobile: +1 812 369 6762
> Blog: http://supunk.blogspot.com
>
>


-- 
Best Regards,
Shameera Rathnayaka.

email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : http://shameerarathnayaka.blogspot.com/

Mime
View raw message