Hi Suresh, After reading this mail, what i understood is, you are not going to solve the problem we have, instead you are replacing one problem with another. Why we need maven module refactoring in the first place is to reduce unnecessary maven modules. What you are suggesting is replacing another set of modules with existing one. Instead explaining our architecture using maven modules we should use maven modules to manage project. let's use wiki to explain our architectural design. According to above structures how many maven modules will be there?
Instead of planing 2.0 or any other release goals lets live with what we have now, let's talk about release 1.0 and then focus on 2.0 goals. For the 1.0 release do we need this level of categorization? Thanks, Shameera. 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 > > > > > > > > -- Best Regards, Shameera Rathnayaka. email: shameera AT apache.org , shameerainfo AT gmail.com Blog : http://shameerarathnayaka.blogspot.com/
