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/
