airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Airavata 0.16 maven module organization
Date Tue, 02 Jun 2015 15:25:20 GMT
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








Mime
View raw message