On 30.01.14 14:12, "Francesco Chicchiriccò" <[email protected]> wrote:
>Having a top-level module (in olingo4, right?) for landing place of the >ODataJClient code (ODATA_4 branch) is a good idea. >Then, the merge process will gradually move stuff from there to the >appropriate place, right? > Sounds good. >On 30.01.14 14:12, "Francesco Chicchiriccò" <[email protected]> wrote: > >>On 29/01/2014 12:23, Klevenz, Stephan wrote: >>>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? >> >>Having a top-level module (in olingo4, right?) for landing place of the >>ODataJClient code (ODATA_4 branch) is a good idea. >>Then, the merge process will gradually move stuff from there to the >>appropriate place, right? >> >>Regards. >> >>>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/ >> >>Involved at The Apache Software Foundation: >>member, Syncope PMC chair, Cocoon PMC, Olingo PPMC >>http://people.apache.org/~ilgrosso/ >> >>
