+ 1. I was planning to bring up this issue also. Probably it will not address what you are raising, but here is a tree output from airavata labs code I was toying with locally. I did not yet compare it with what you proposed, I will do so later today.
├── airavata-api │ ├── airavata-api-interface-descriptions │ ├── airavata-api-java-stubs │ ├── airavata-api-server │ ├── airavata-data-models │ ├── api-security-manager ├── clients │ ├── airavata-client-cpp-sdk │ ├── airavata-client-java-sdk │ ├── airavata-client-php-sdk │ ├── airavata-client-python-sdk │ ├── airavata-sample-examples │ └── airavata-xbaya-gui ├── components │ ├── commons │ ├── component-interface-descriptions │ ├── component-services │ │ ├── credential-store-service │ │ ├── orchestrator-service │ │ ├── task-executor-service │ │ └── workflow-interpreter-service │ ├── component-clients │ │ ├── credential-store-client │ │ ├── orchestrator-client │ │ ├── task-executor-client │ │ ├── workflow-interpreter-client │ │ └── messaging │ ├── task-adaptors │ │ ├── compute │ │ └── data-movement │ ├── registry │ │ ├── app-catalog │ │ ├── experiment-catalog │ │ └── resource-catalog │ └── workflow-interpreter ├── distribution ├── integration-tests > On May 29, 2015, at 10:15 AM, Shameera Rathnayaka <[email protected]> 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.
