Did you already close your refactoring JIRA? I thought work can be done under that one. Otherwise I can open one.
See lot of concepts in "edm" and "edm.provider" are similar/same, they both build metadata about service and service access, I did not understand why they were created as two separate interfaces, can you tell me reasons behind it? As you see, as a root apis they spread and cause the confusion in naming. +1 on removing ".provider". +1 on package private. Ramesh.. ----- Original Message ----- > 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 > > > > > > > > >
