Hi Christian, Great, we are same page then. First of all, if packages can include a package documentation file to describe what they are used for, that would really good.
I have not yet used "annotations" and "client" modules so not sure what those "domain" and "annotation" packages yet. common-api ---------------- org.apache.olingo.commons.api.data ==> Shows all the Data objects of OData responses org.apache.olingo.commons.api.edm ==> Represents a EDM Objects created during the URI Parsing org.apache.olingo.commons.api.edm.provider ==> objects created during CSDL document parsing. "Edm" would have been right prefix for this, since can not be used how about "Csdl"? They represent objects from this document. common-core ----------------- org.apache.olingo.commons.core.edm.provider ==> seems to extend classes from "common-api" package "org.apache.olingo.commons.api.edm" which itself is confusing, because I would have expected them in "org.apache.olingo.commons.core.edm" package not "org.apache.olingo.commons.api.edm.provider". These are so similar to provider classes, and used by URL parsing routines, gets confused with provider classes. So, at a minimum change the package the name here. server-api and server-core -------------------------- I am not sure we really need interface abstraction really needed for those "uri" interfaces, but if somebody wants to develop a new server these will be useful. odata-client-core ------------------- org.apache.olingo.client.core.edm.xml ==> This one always gets me. These are exactly same as the provider classes above, except that they have JSON deserialization code. I am not sure what is being provided by "jackson" library here, olingo practically provides each step of the parsing, its not like JAXB where the XML object created for based on data structure. So, for seem these classes seem verbose. Two things we can do. Either make them package private so that only framework classes have visibility for parsing the return response for client. Or move all the Deserializer code into single utility class and get rid of all classes (not sure this possible), otherwise do not depend on json library (jackson) based automatic parsing, as I mentioned above this is providing little or no automation in creation object. Also, there is no $metadata payload coming in JSON yet, what are these used for? Thank you. Ramesh.. ----- Original Message ----- > Hi Ramesh, > > naming is incredibly important in my opinion and I am always thankful for any > kind of feedback on that. > > I had the same thoughts when creating the API and Provider classes. My > thought there was to have the edm provider beans without EDM prefix and the > EDM API with the prefix. I did not see that data beans at that time so there > is a Property in the edm provider and a property in the data package. > > My first thought would be to prefix all Provider classes with "Prov" or > something like that but I did not have the time for that. > > If you have any other naming ideas please let me know. > > Best Regards, > Christian > > -----Original Message----- > From: Ramesh Reddy [mailto:[email protected]] > Sent: Donnerstag, 16. April 2015 21:55 > To: [email protected] > Subject: Re: Renaming classes in "org.apache.olingo.commons.api.edm.provider" > > scratch that, I see some other classes with Edm prefix already. Surely as you > can see even after looking at the code for sometime I still get confused > with similarly named classes. Renaming them to correctly represent their > function is really going help understand for service developers IMO. I > understand they are in different packages, but does not do whole lot of > good. > > I am still learning -:) > > Ramesh.. > > ----- Original Message ----- > > Hi, > > > > Since we are refactoring lot of common-api, common-core code, is it > > possible > > to rename classes in "org.apache.olingo.commons.api.edm.provider" package > > in > > the common-api module to prefix something like "Edm", so they are > > EdmAction, > > EdmActionImport etc? I always get confused which classes to select when > > some > > of the classes with same name show up from > > "org.apache.olingo.commons.api.data" package. By adding this prefix, it > > would be much more clear IMO. > > > > what do you guys think? > > > > Ramesh.. > > http://teiid.org > > > > >
