Hi Ramesh, sorry for my late response about this.
common-api: Good Idea! common-core I chose this package name to show that this is an EDM implementation using the provider classes. Technically someone could implement the Edm Interfaces completely different. This is why I put them under core.edm.provider. The AbstractEdm.class in core.edm is independent from that and just handles caching. WDYT about this design? I could also live with deleting the .provider name from the package naming. Server-api/ server-core Sven was the one to implement the URI stuff so I don`t want to make assumptions there. Client-core: This is tricky. We have to use Jackson in the client code to provide an android implementation since the native xml parsers are not available on android devices. Since this is a given we extend the commons.api.provider classes to keep the commons module and the server module free from any Jackson dependencies. As you have stated these classes are verbose and I do not like that but I could not come up with a better solution than this. Although package private sounds like a very good idea! Would you like to create some JIRA issues for this so we can track the progress? Best Regards, Christian -----Original Message----- From: Ramesh Reddy [mailto:[email protected]] Sent: Freitag, 17. April 2015 17:14 To: [email protected] Subject: Re: Renaming classes in "org.apache.olingo.commons.api.edm.provider" 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 > > > > >
