Hi together,

to prevent a possible bigger merge with the master and I did not read any 
objections
I merged the feature branch back into master.

See latest commit: 
https://git1-us-west.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=61500e685fca852fac301f473fcca8a2918f887e
 
<https://git1-us-west.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=61500e685fca852fac301f473fcca8a2918f887e>

As always, feedback is welcome  ;o)

Best regards, 
Michael

> On 30 Apr 2015, at 06:15, Bolz, Michael <[email protected]> wrote:
> 
> Hi,
> 
> I extracted the client related parts into to ³client-api/core² modules and
> updated feature branch OLINGO-564
> (https://git1-us-west.apache.org/repos/asf?p=olingo-odata4.git;a=shortlog;h
> =refs/heads/OLINGO-564).
> 
> As always: Feedback is welcome  ;o)
> 
> Best regards, 
> Michael
> 
> 
> 
> On 29/04/15 07:57, "Bolz, Michael" <[email protected]> wrote:
> 
>> Hi Ramesh,
>> 
>>> Suggestions 
>>> 1) Is there is any strong reason to have both "common-api" and
>>> "common-core". Can me move these packages into one module like
>>> "common-core"? for client and server api/impl makes sense as someone
>>> could provide an alternative implementation.
>> 
>> The separation between API (³api²) and implementation (³core²) was
>> intentionally that it is clearly evident which parts are ³visible² to an
>> user and must be backward capable.
>> In Olingo V2 this concept helped a lot to achieve that an update of the
>> library does not lead to compilation errors.
>> For that reason I would prefer to keep the separation.
>> 
>>> 
>>> 2) Can we rename " commons-api
>>> ==>org.apache.olingo.commons.api.edm.provider" to " commons-api
>>> ==>org.apache.olingo.commons.api.edm.csdl" or "
>>> org.apache.olingo.commons.api.csdl". Same goes to
>>> "edm.provider.annotation" package.
>> 
>> I agree with your suggestion and prefer
>> ³org.apache.olingo.commons.api.edm.csdl².
>> Furthermore I would suggest to rename
>> ³org.apache.olingo.commons.api.domain² to
>> ³org.apache.olingo.commons.api.client², or better this should be moved to
>> ³org.apache.olingo.client.api.domain².
>> However...
>> 
>>> 
>>> 3) Next confusing part is package
>>> "org.apache.olingo.commons.api.domain" package in "commons-api" and its
>>> implementation in "common-core". This is parallel package what looks
>>> like same/similar intentions as "org.apache.olingo.commons.api.data".
>>> These are only used to serialize and deserialize content in client
>>> modules. If they are only designed for client they should have been
>>> (should be moved to) in the client, if not
>>> "org.apache.olingo.commons.api.data" should not have existed to begin
>>> with. It is quite possible I am not seeing the intent of this package
>>> too, so in that case if you can explain that would be great.
>> 
>> Šthis could be not that easy.
>> As far as I knew is this ³confusing part² a (legacy) result of the merge
>> of the client contribution with the server contribution.
>> I will check if its possible to move the ³client-only² code from the
>> ³commons² into the ³client² modules.
>> 
>> Nevertheless I would prefer to do a merge back of the current state (of
>> OLINGO-564) into the master branch.
>> 
>> Best regards,
>> Michael
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to