Hi Suresh, Why we need component-interface-descriptions (which resides outside) and interfaces inside the component ?
Thanks.. Chathuri On Tue, Jun 2, 2015 at 11:25 AM, Suresh Marru <sma...@apache.org> wrote: > Hi All, > > While we let other thread on leaf modules going, here is a abstract > suggestion for maven modules. Please critique: > > We need to ensure the directory structure used for code navigability > should not created additional maven release artifacts. In 0.15 and earlier > versions, we have been releasing these empty artifacts for no good reason. > > ├── airavata-api > │ ├── airavata-api-interface-descriptions (these are the thrift IDL’s) > │ ├── airavata-data-models (thrift generated data models, used by > clients, components and api server) > │ ├── airavata-api-java-stubs (thrift generated java stubs used by > clients as well has servers for implementations) > │ ├── airavata-api-server (api service handlers and startup classes) > │ ├── api-security-manager (gsoc project to add API level oauth security) > ├── clients (self explanatory client SDK’s - thrift generated code plus > samples) > │ ├── airavata-client-cpp-sdk > │ ├── airavata-client-java-sdk > │ ├── airavata-client-php-sdk > │ ├── airavata-client-python-sdk > │ ├── airavata-sample-examples > │ └── airavata-xbaya-gui > ├── distribution > ├── integration-tests > > For component organization we can go any number of ways. The fundamental > proposition I have is components are literally loosely coupled and live by > themselves. > > One suggestion is to organize all component interface descriptions, > services and clients into and then component implementations (which > internally can have interfaces, implementations of these interfaces, util > packages and so forth). > > ├── 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 > │ ├── orchestrator-component-impl > │ │ ├── orchestrator-interface > │ │ └── orchestrator-impl…. > │ ├── registry > │ │ ├── app-catalog > │ │ ├── experiment-catalog > │ │ └── resource-catalog > > Other suggestion is to organize by a component. Within the component it > can also have the service interfaces and clients. > > This facilitates to have one more then one component implementing the same > component interface. They are used based on usecases and stability. In no > scenario we should have one component implementation depending on other > component’s implementation. If there is really a common functionality we > should have a module in commons used by both. At most the component should > only have dependency to component's thrift clients or in case of registry > and messaging appropriate java clients. > > This is again abstract, once we debate on the down sides and address them, > we can make this concrete to cover it all. > > Cheers, > Suresh > > > > > > > >
