Hi Francesco, I will summarize the structure of the OData 4.0 code line. The code line is in an early development state and not complete.
Basically Olingo distinguish between client, server and common parts. Furthermore it separates api from core where core is the implementation part which should be required for runtime only. The idea is to have at the end one client bundle and one server bundle where the client does not inherit parts and dependencies of the server and vice versa. The separation of api should guarantee to change the core without breaking the api. Module Details: client.api ODataConsumer - implements a runtime delegate to the core deserializer - API to access deserialization results common.api EDM - model and provider interfaces exception - common exception types server.api uri - an OData uri model as the result of an OData uri parser client.core core - runtime delegate deserializer - implementation for JSON only (uses Jackson) common.core edm - primitive type conversion and provider implementation server.core uri.antlr - ANTLR based uri parser fit full integration JUnit tests (client calls server) ref a reference scenario implementation (for testing and demo) There is one top level module which is called odata-lib. The plan is to get extensions (e.g. JPA) as a sibling to this. We can create another top level module (data-client) for hosting your client code. Then we can continue merge and re-factoring discussion. WDYT? Regards, Stephan On 28.01.14 20:23, "Francesco Chicchiriccò" <[email protected]> wrote: >Hi all, >Eduard Koller has recently announced [1] the wiling to contribute the >code from ODataJClient [2] to Apache Olingo. > >Waiting for the proper contribution to complete, and supposing this >community is going to accept it, I'd like to introduce you to >ODataJClient so that we can start discussing about the best way to merge >its code to the current Olingo codebase. > >The code at GitHub shows two main branches: > 1. master contains the stable, complete and fully-compliant to OData >3.0 protocol specification, implementation > 2. ODATA_4 contains instead the current work we are carrying out to >add OData 4.0 compatibility on top of existing OData 3.0 features, hence >obtaining a client library which is able to deal with both protocol >versions. > >It makes sense to merge only the code from ODATA_4 since it already >includes all features from master. >All wiki pages at GitHub (including user guide [3]) refer anyway to >master, so they are all quite outdated. > >ODataJClient is meant to provide Java clients with capabilities to >interact with OData 3.0 / 4.0 services at two levels: > > 1. Engine >Low-level communication layer taking care of actual REST communication >and OData entity (de)serialization, exposing methods to hook into the >OData protocol for manipulating entities and invoking actions and >functions. >Engine is designed to perform the great majority of operations *without* >requiring any metadata information. >A typical engine interaction is shown by [4] (there are RequestFactory >object for all request types in OData: entity set, entity, property, >property value, metadata, batch, invoke, ...) > > 2. Proxy >Inspired by JPA, this layer will convert any local change to POJOs and >any local invocation of annotated interfaces' methods into actual calls >to the Engine layer. >Proxy will required metadata information for any operation. >A sample proxy interaction is shown by [5]. > >The formats supported are both Atom and JSON light (in its variants), >even though enhancements in OData 4.0 are still to be developed; there >is no support for JSON verbose. > >A quick tour of the source code shows a Maven multi-module project: >* engine-xml >ODataJClient is fully compatible with Android (a sample application [6] >is provided): for this reason some problematic dependencies - mainly >related to XML parsing - are re-packaged via the JarJar Maven plugin and >provided by this module. >* engine >Contains the Engine layer code. >* extensions >Provides extensions (currently only the class for enabling OAuth >authentication). >* plugin >Maven plugin for generating POJOs from $metadata - this is a required >precondition for the Proxy layer to work; an example of this is also >included in [6]. >* proxy >Contains the Proxy layer code. >* test-auth-rproxy >A simple reverse proxy adding Basic Authentication on top of an existing >OData service: this was needed when originally developing ODataJClient, >because a non-public sample service was available. I don't think there >is need to import this module. > >Besides unit tests, the code is completed with a full set of integration >end-to-end tests requiring a non-public sample service instance: I think >such tests are pretty useless when moving at Olingo. > >As you can see from pom.xml files, the external dependencies are: > 1. HttpComponents HttpClient > 2. Jackson (for both JSON and XML support) > 3. Aalto (provides StAX parser working in Android after repackage) > >################## > >Once said all that (wow, it's longer than I expected), could you please >provide a description of olingo4 structure and some merging suggestions? > >Regards. > >[1] http://markmail.org/message/zg3ofstcyhpfamtx >[2] https://github.com/MSOpenTech/ODataJClient/ >[3] https://github.com/MSOpenTech/ODataJClient/wiki/User-guide >[4] https://gist.github.com/ilgrosso/8674028 >[5] https://gist.github.com/ilgrosso/30ac97913d953dce3ea8 >[6] https://github.com/Tirasa/ODataJClientOnAndroidSample > >-- >Francesco Chicchiriccò > >Tirasa - Open Source Excellence >http://www.tirasa.net/ > >ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member >http://people.apache.org/~ilgrosso/ >
