That's actually what cloud-api is supposed to be. The problem is not there. The problem is none of the plugin code should have build dependencies on cloud-core and cloud-server. The Manager interfaces were not intended for outside consumption. That will achieve better separation.
We can talk about breaking cloud-api into cloud-rest-api, cloud-plugin-api, cloud-resource-api to reduce confusion as to what constitutes cloudstack api. --Alex > -----Original Message----- > From: Rohit Yadav [mailto:[email protected]] > Sent: Wednesday, January 09, 2013 3:53 PM > To: [email protected] > Subject: [DISCUSS] Breaking out interfaces to cloud-utils or create a new > artifact cloud-contract > > Hi all, > > One of the challenges of writing good structural code in CloudStack is that > the > artifacts and their classes depend on each other with no code/filesystem > structure. I want to discuss if it's a good idea to split all the interface > classes > files (from cloud-api, cloud-server, cloud-core) to either cloud-utils (which > already provides a lot of reusable utils) or move them to a cloud-contract or > cloud-interface artifact whose only purpose would be to provide interfaces > or contracts between CloudStack components. The rules would be that > cloud-utils provides reusable methods/utils via static methods and cloud- > contract would just provide interfaces both of whose classes can be > dependent on other classes within their artifact but they should be > independent of anything else. > > This would be just a move refactor, can be done after javelin is merged, can > be done after 4.1, but would make it easier to write components so they > won't have have cyclic dependency, tight coupling and a better filesystem > structure. > > Regards.
