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/
