1. I see. (a) Atom is not made into official standard, (b) JSONEntry/AtomEntry become more like part of jackson implementation, so I think it is ok if you want to move their api classes into core, and just let api layer expose ODataEntry/ODataEntity, on top of which strong-typed proxies will be code gen'ed.
2. (a) I would vote for org.apache.olingo, removing odata4, (b) I would suggest also remove v4 from 'org.apache.olingo.odata4.client.api.edm.v4' There is not much worry about protocol change versus our client change, but protocol change versus user code change. If we require user code to import 'v4', then when we add 'v5', user code still work without changing 'v4'->'v5', their possible oversight may make our 'v5' never take effect, sounds error-prone. Thanks,-Challen -----Original Message----- From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] Sent: 2014年3月5日 16:37 To: dev@olingo.incubator.apache.org Subject: Re: [OLINGO-169] Work in progress See my answer below... On 05.03.14 09:10, "Francesco Chicchiriccò" <ilgro...@apache.org> wrote: >On 05/03/2014 05:14, Challen He wrote: >> It is well understood >> org.apache.olingo.odata4.client.core.edm.EdmEnumTypeImpl >> implements >> org.apache.olingo.odata4.commons.api.edm.EdmEnumType >> >> but it composes org.apache.olingo.odata4.client.api.edm.xml.EnumType, >>which is under the 'api' namespace, since this class is not really >>api/interface but part of client's internal implementation of the >>interface, should it be moved to 'core' namespace? > >There are 3 api/core pairs: commons, client and server. > >ODataJClient used to provide different access levels: > >1. the highest, JPA-like, level (in the proxy module), 2. the middle - >with some abstraction degree, but still close to the protocol - for >classes like as ODataReader, ODataWriter and ODataBinder manipulating >some abstractions like as ODataEntity, ODataEntitySet (in the engine >module) 3. the lowest - with entities coming directly from the protocol >for classes like Serializer, Deserializer, JSONEntry, AromEntry > >The same layering will be brought into Olingo: this is the reason why >org.apache.olingo.odata4.client.api.edm.xml.EnumType is under >client-api (not commons-api as instead is for EdmEnumType): it is for >3rd party applications that don't want to access the middle-level but >wants to stay on lowest, with still some handful abstraction. > >> Also got another concern around namespace naming: now 'v4' is >>included in namespace, suppose in future there is 'v5' odata protocol, >>then: even if the client usages such as query/post stay unchanged, >>user still needs to update their codes instead of taking new client as >>non-breaking change. > >First of all, the code is located at the 'olingo-odata4' repository and >Maven artifacts are named accordingly as >org.apache.olingo:olingo-odata4-*-incubating (where the 'incubating' >suffix will be removed after graduation): this would just mean that any >client will know upfront that it is dealing with v4. 'odata4' as part of namespace has just logical reasons. We have already 'odata2', could have 'odata3' and will have 'odata4'. On the other hand I share concerns that we end up in 'odataN' where N can be a larger number. That makes it quite difficult to use and requires always decisions which library to use. To have a very simple namespace would be nicer. Just to have org.apache.olingo would be my favorite. My argument is that this is the OASIS version of the OData protocol. I also don't believe that we will come up with new implementations from scratch if OASIS releases new versions (4.1, 5 ...). A design goal could be to keep the library extendible for new protocol versions. You are doing this already for v3 and v4 serialization. If we just go for org.apache.olingo then we should re-factor artifact names accordingly. That the git repository is named odata4 is not an issue but it can change as well after graduation. WDYT? > >Anyway, are you supposing that protocol upgrade - including discussion >and approval by the Oasis committee - occurs frequently than client >application upgrade? > >Regards. > >> -----Original Message----- >> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >> Sent: 2014年3月3日 15:50 >> To: dev@olingo.incubator.apache.org >> Subject: Re: [OLINGO-169] Work in progress >> >> Hi all, >> a quick update. >> >> I am currently implementing, as suggested below, the current set of >>commons-api Edm interfaces on client side, in the same way they are >>implemented on server side, e.g. on top of another whole set of classes: >> for example >> >> org.apache.olingo.odata4.server.core.edm.provider.EdmEnumImpl >> >> implements >> >> org.apache.olingo.odata4.commons.api.edm.EdmEnumType >> >> by delegating to an >> >> org.apache.olingo.odata4.server.api.edm.provider.EnumType >> >> server object which contains the actual information about the enum >>type; in the same fashion >> >> org.apache.olingo.odata4.client.core.edm.EdmEnumTypeImpl >> >> is implementing the same EdmEnumType above by delegating to an >> >> org.apache.olingo.odata4.client.api.edm.xml.EnumType >> >> client interface, whose concrete instances (different for V3 and V4) >>are actually constructed by the Jackson XML parser. >> >> At the end of this process I should be able to obtain what discussed >>below, hence I am fine. >> I am finding many similarities between server's EdmEnumImpl and >>client's >> EdmEnumTypeImpl: is it fine to you to introduce >>AbstractEdmEnumTypeImpl in commons-core? (and so on, for all other Edm >>interfaces implementions). >> >> Besides this, I will also remove usage of client-side EdmType and >>EdmSimpleType classes with the commons EdmType hierarchy. >> >> I am going to open two subtasks of OLINGO-169 in JIRA for these. >> >> Few questions I have after looking closely to Edm interfaces: >> >> 1. Does EdmServiceMetadata#getMetadata (which returns an InputStream >>containing the metadata document) make sense on client side? I'd say >>no, since client code actually *builds* an EdmServiceMetadata from an >>InputStream. >> Shall we remove such method from common interface? >> >> 2. What is EdmEntitySetInfo#getEntitySetUri expected to provide? >>Isn't the external URI of an EntitySet provided by the service >>document (and only for entity sets with 'IncludeInServiceDocument' set to >>true)? >> >> 3. Does Edm#getEntityContainer(FullQualifiedName) make sense? CSDL >>specification (at the beginning of chapter 13) says: "Each metadata >>document used to describe an OData service MUST define exactly one >>entity container." >> I would have expected Edm#getEntityContainer (e.g. without arguments). >> >> Regards. >> >> On 28/02/2014 09:09, Klevenz, Stephan wrote: >>> Sorry for responding late. >>> >>> I am not sure if there is still a problem with using edm interfaces >>> from commons. I can share [1] of OData 2.0 library which has a >>> deserializer for metadata and which returns an interface. >>> >>> Setters in the interface not necessary. They are required for >>> implementation only. The implementation in [1] is stax based and >>> with that I currently don not see issues with cyclic element dependencies. >>> >>> If there is a need to change the edm interface so that a client can >>> better deal with it, just make a proposal. We will then cross check >>> for the server case and if there is no issue ... just do it. >>> >>> Regards, >>> Stephan >>> >>> >>> [1] >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata2.gi >>> t; >>> a=blo >>> b;f=odata2-lib/odata-core/src/main/java/org/apache/olingo/odata2/cor >>> e/ >>> ep/co >>> nsumer/XmlMetadataConsumer.java;h=e8677a1112aa319d9b12fa615b39015e63 >>> fc >>> e1d2; >>> hb=HEAD >>> >>> >>> On 26.02.14 17:05, "Challen He" <chall...@microsoft.com> wrote: >>> >>>> For (1), yes, I agree (the new work is to re-use ODataJClient >>>> parser, and then convert *"old" ODataJClient Edm interfaces* result >>>> --> *Olingo 4 common Edm interfaces* result) About (2), I think so, >>>> unifying Edm interfaces is one of the goals of moving to ASF, and >>>> the resulted Edm interfaces should be 'strong typed' >>>> rather than 'weak typed' model. (we can take a look at and >>>> prioritize all tasks for better plan & schedule) >>>> >>>> Thanks,-Challen >>>> >>>> -----Original Message----- >>>> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >>>> Sent: 2014年2月26日 23:45 >>>> To: dev@olingo.incubator.apache.org >>>> Subject: Re: [OLINGO-169] Work in progress >>>> >>>> Hi Challen, >>>> thanks for your suggestions: I was actually more willing to check >>>> >>>> (1) whether my understanding, e.g. the concept difference between >>>>"old" >>>> ODataJClient Edm interfaces and Olingo 4 common Edm interfaces, is >>>>correct >>>> (2) if so, whether it is immediately necessary to change the client >>>>XML Metadata parser accordingly: being not a trivial task, I want to >>>>be sure it is needed before committing to it >>>> >>>> Hope this clarifies. >>>> Regards. >>>> >>>> On 26/02/2014 16:33, Challen He wrote: >>>>> Hi Francesco, >>>>> >>>>> I think cross/circle reference in Edm is inevitable: not only >>>>>EntityContainer but also EntityType itself may refer to EntityType, >>>>>e.g. >>>>> entity type 'Employee' has a property of 'Manager' type, and >>>>>'Manager' >>>>> type itself contains a collection of 'Employee'. So the job of >>>>>figuring out their relationships will be taken by user /client / >>>>>server code if common doesn't do it. >>>>> >>>>> A 2-phased solution is: phase1 - parse CSDL xml doc into a set of >>>>> intermediate csdl objects (they only have weak reference like the >>>>> mentioned String field named 'entityType'), phase2 - use csdl >>>>> objects to first build all edm type objects (EdmComplexType, >>>>> EdmEntityType, EdmEnumType..., need to handle circle references >>>>> among them), then these edm type objects are used to build >>>>> EntitySet/Container/function/action/annotation term... >>>>> >>>>> I think we can start with the assumption of no circle reference >>>>> and later add support for it, but in the design it looks ok for >>>>> all Edm interface definitions to have 'strong type' references >>>>> like 'EdmEntitySet' -> 'EdmEntityType', or 'EdmEntityType' -> >>>>> another 'EdmEntityType' ... >>>>> >>>>> (though I am not 100% sure but personally I think entity >>>>> interfaces with getter only will work, considering that they will >>>>> be created by >>>>> factory/builder) >>>>> >>>>> Thanks,-Challen >>>>> >>>>> -----Original Message----- >>>>> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >>>>> Sent: 2014年2月26日 19:14 >>>>> To: dev@olingo.incubator.apache.org >>>>> Subject: Re: [OLINGO-169] Work in progress >>>>> >>>>> Hi, >>>>> I have spent some more time in comparing the commons-api Edm >>>>> interfaces and their client-api counterparts and I am going to try >>>>> to explain better my concerns. >>>>> >>>>> Let's take again the sample below: >>>>> >>>>> <EntitySet Name="Products" EntityType="ODataDemo.Product"> >>>>> <NavigationPropertyBinding >>>>> Path="ODataDemo.FeaturedProduct/Advertisement" >>>>>Target="Advertisements"/> >>>>> <NavigationPropertyBinding Path="Categories" >>>>>Target="Categories"/> >>>>> <NavigationPropertyBinding Path="Supplier" Target="Suppliers"/> >>>>> <NavigationPropertyBinding Path="ProductDetail" >>>>> Target="ProductDetails"/> >>>>> </EntitySet> >>>>> >>>>> Currently, the way odata4-client-core works will barely translate >>>>> this piece of information from XML to Java object(s), where an >>>>> instance of EntitySetImpl - implementation of EntitySet [9] - has >>>>> a String field named 'entityType' with value 'ODataDemo.Product'. >>>>> >>>>> If you take a look at EdmEntitySet [10] instead, this interface >>>>> supposes that an EdmEntitySetImpl will have an EdmEntityType field >>>>> named 'entityType', whose value is a reference to an >>>>> EdmEntityTypeImpl instance for ODataDemo.Product. >>>>> >>>>> This fact implies that the metadata XML parser will need, when >>>>> encountering the XML attribute >>>>> >>>>> EntityType="ODataDemo.Product" >>>>> >>>>> to look at EdmEntityTypeImpl instances built so far during parsing >>>>> and associate the one with name 'ODataDemo.Product' to the >>>>> EdmEntitySetImpl under construction. >>>>> All that where potentially ODataDemo.Product could be not defined >>>>> in the current metadata document but in one of referenced metadata >>>>> documents. >>>>> >>>>> As you can see, this is a *huge* difference: consider, for >>>>> example, that the instances to link to the one under construction >>>>> could not even be built yet - see the NavigationPropertyBinding's >>>>> target above, where "Categories" could be an EntitySet or a >>>>> Singleton not yet encountered in the XML document being parsed. >>>>> >>>>> Before starting this considerable change effort, I'd like to >>>>>understand if I am right in the finding above and also if you think >>>>>it is worth to change the way how the client metadata XML parser >>>>>currently works. >>>>> If I am right, in fact, we need either to give up on making the >>>>>effort to use the same Edm interfaces client- and server-side or >>>>>the change described above must be implemented. >>>>> >>>>> Another minor issue I have with commons-api Edm interfaces is that >>>>> they mostly lack setter methods: is it fine to introduce them? It >>>>> will make the XML parser work a little less hard. >>>>> >>>>> Regards. >>>>> >>>>> On 25/02/2014 17:16, Amend, Christian wrote: >>>>>> 1. Yes using the EdmType hierarchy should work just fine. I Am >>>>>> not quite sure what you mean by parsing type expressions. Do you >>>>>> mean that you have a Java String and would like to have an >>>>>> EdmPrimitiveType for this? >>>>>> >>>>>> 2. I see your concern. We had a similar question with V2 when we >>>>>> tried to implement a client. We could delete these info objects >>>>>> but would then have to provide methods like getEntitySets() >>>>>> (returning a list of >>>>>> EdmEntitySets) at the EDM directly. Otherwise how would a client >>>>>> access the entity sets without knowing their name first. >>>>>> >>>>>> 2.) b+c) then lets move the V3 interfaces into commons. >>>>>> >>>>>> Best Regards, >>>>>> Christian >>>>>> >>>>>> -----Original Message----- >>>>>> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >>>>>> Sent: Dienstag, 25. Februar 2014 16:10 >>>>>> To: dev@olingo.incubator.apache.org >>>>>> Subject: Re: [OLINGO-169] Work in progress >>>>>> >>>>>> On 25/02/2014 14:38, Amend, Christian wrote: >>>>>>> Hi Francesco, >>>>>>> >>>>>>> 1. I don`t quite understand where your concern is there. Could >>>>>>> you please clarify? >>>>>> Let's put it differently: is there already something for parsing >>>>>>type expressions? >>>>>> Moreover: is there already something to represent types? I guess >>>>>>that EdmType[8]'s hierarchy should fit the job, right? In this >>>>>>case I should be able to remove [1][2][3][4][5] and use EdmType >>>>>>descendants. >>>>>> >>>>>>> 2.) >>>>>>> a) The info interfaces are there because there was no way to get >>>>>>> a list of all entity sets inside the edm without knowing their name. >>>>>>> Also this information is needed for the service document. >>>>>> Ok: I am not sure whether the existing interfaces are suitable, >>>>>>from a client perspective; consider that client will instantiate >>>>>>the Edm interfaces' implementations by parsing the $metadata XML >>>>>>content. >>>>>> As an example, please see how to represent something like as >>>>>> >>>>>> <EntitySet Name="Products" EntityType="ODataDemo.Product"> >>>>>> <NavigationPropertyBinding >>>>>> Path="ODataDemo.FeaturedProduct/Advertisement" >>>>>> Target="Advertisements"/> >>>>>> <NavigationPropertyBinding Path="Categories" >>>>>>Target="Categories"/> >>>>>> <NavigationPropertyBinding Path="Supplier" Target="Suppliers"/> >>>>>> <NavigationPropertyBinding Path="ProductDetail" >>>>>> Target="ProductDetails"/> </EntitySet> >>>>>> >>>>>> With EntitySet [9] this will result in (please excuse the >>>>>> pseudo-JSON >>>>>> representation): >>>>>> >>>>>> EntitySetImpl { >>>>>> name: "Products", >>>>>> entityType: "ODataDemo.Product", >>>>>> includeInServiceDocument: true, >>>>>> navigationPropertyBindings: [ >>>>>> NavigationPropertyBindingImpl { >>>>>> path: "ODataDemo.FeaturedProduct/Advertisement", >>>>>> target: "Advertisements" >>>>>> }, >>>>>> ... >>>>>> ] >>>>>> } >>>>>> >>>>>> i.e. this is more or less the translation of the XML snippet above. >>>>>> >>>>>> With EdmEntitySet [10] instead the representation is much more >>>>>> involved, mostly because metadata is something that is to be >>>>>> built and then pushed out as XML, rather than parsed from XML. >>>>>> >>>>>> Not sure I actually succeeded in expressing my concerns... >>>>>> >>>>>>> b) No I think the interfaces in [6] should cover all aspects of >>>>>>> the EDM. If not this is functionality which has to be added. >>>>>>> c) If they can coexist without causing conflicts I would put the >>>>>>> V3 interfaces in the commons API. We might not support this on >>>>>>> server side from the beginning but a later refactoring would be >>>>>>> cumbersome IMHO. Although I am open for other opinions. >>>>>> The current client Edm interfaces [7] are available for V3 and V4 >>>>>>without conflicts, so there should be no problem on having them in >>>>>>odata4-commons-api, without providing server implementations for >>>>>>V3's. >>>>>> >>>>>> Regards. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >>>>>>> Sent: Dienstag, 25. Februar 2014 14:06 >>>>>>> To: dev@olingo.incubator.apache.org >>>>>>> Subject: [OLINGO-169] Work in progress >>>>>>> >>>>>>> Hi all, >>>>>>> I have reached a fair stable point for merging ODataJClient's >>>>>>>Metadata parsing into olingo-odata4 (in the 'olingo169' GIT >>>>>>>branch): >>>>>>> now metadata parsing works either for V3 and V4 (few unit tests >>>>>>>have been added in olingo-odata4-client-core ). >>>>>>> >>>>>>> At this point I have two main concerns before considering the >>>>>>>work for >>>>>>> OLINGO-169 completed (and consequently merge olingo169 into >>>>>>>master): >>>>>>> >>>>>>> 1. types >>>>>>> >>>>>>> EdmType [1] is an interface (with concrete implementations >>>>>>> available for >>>>>>> V3 and V4) whose main purpose is parsing type expressions (like >>>>>>> as >>>>>>> 'Collection(ODataDemo.Product)') into a meaningful >>>>>>> representation, e.g. >>>>>>> EdmSimpleType [2], EnumType [3], ComplexType [4] or EntityType >>>>>>> [5] and also to provide other useful information (is this a collection? >>>>>>> does it have a base type?). >>>>>>> >>>>>>> I am sure that this duplicates something else in odata-olingo4. >>>>>>> but I need some guidance about how to replace [1][2][3][4][5]. >>>>>>> Also, I suppose that a better location for such items is >>>>>>> olingo-odata4-commons-api rather than olingo-odata4-client-api >>>>>>> (where they reside ATM). >>>>>>> Who would like to volunteer? >>>>>>> >>>>>>> >>>>>>> 2. Edm interfaces >>>>>>> >>>>>>> olingo-odata4-commons-api holds in [6] the current set of Edm >>>>>>> interfaces implemented server-side whilst I have temporarily put >>>>>>> the set of Edm interfaces implemented client-side in >>>>>>> olingo-odata4-client-api's [7] (and subpackages). >>>>>>> >>>>>>> Again, I need to understand how to reconcile and consolidate >>>>>>> these two sets (into olingo-odata4-commons-api of course), but >>>>>>> there are several aspects I don't understand: >>>>>>> >>>>>>> (a) what is the purpose of *Info interfaces (like as >>>>>>> EdmEntitySetInfo)? what's the usage difference with EdmEntitySet? >>>>>>> (b) is the set from [6] still to be completed? >>>>>>> (c) would it be fine to put in [6] the merge with all >>>>>>> interfaces from [7], including V3's or is it better to keep V3's >>>>>>> in olingo-odata4-client-api? >>>>>>> >>>>>>> >>>>>>> Thanks for your support. >>>>>>> Regards. >>>>>>> >>>>>>> [1] >>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4. >>>>>>> gi >>>>>>> t >>>>>>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/ >>>>>>> ol >>>>>>> in >>>>>>> g >>>>>>> o/odata4/client/api/edm/EdmType.java;h=5a480d72cbbc707696dd358e1 >>>>>>> 17 >>>>>>> 46 >>>>>>> 8 >>>>>>> f0f87980fb;hb=olingo169 [2] >>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4. >>>>>>> gi >>>>>>> t >>>>>>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/ >>>>>>> ol >>>>>>> in >>>>>>> g >>>>>>> o/odata4/client/api/data/EdmSimpleType.java;h=7d44c376e89b084c6e >>>>>>> 85 >>>>>>> 63 >>>>>>> c >>>>>>> 63317012284278795;hb=olingo169 [3] >>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4. >>>>>>> gi >>>>>>> t >>>>>>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/ >>>>>>> ol >>>>>>> in >>>>>>> g >>>>>>> o/odata4/client/api/edm/EnumType.java;h=614c5e1e85a731ae80de5689 >>>>>>> 9e >>>>>>> 7d >>>>>>> 9 >>>>>>> d82ae846bf0;hb=olingo169 [4] >>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4. >>>>>>> gi >>>>>>> t >>>>>>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/ >>>>>>> ol >>>>>>> in >>>>>>> g >>>>>>> o/odata4/client/api/edm/ComplexType.java;h=929d1b83f4db4c290b068 >>>>>>> 1b >>>>>>> 7d >>>>>>> 6 >>>>>>> 29b9d0545f33a5;hb=olingo169 [5] >>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4. >>>>>>> gi >>>>>>> t >>>>>>> ;a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/ >>>>>>> ol >>>>>>> in >>>>>>> g >>>>>>> o/odata4/client/api/edm/EntityType.java;h=37ebc359f0ec36e439b3a8 >>>>>>> 55 >>>>>>> 5e >>>>>>> 2 >>>>>>> 3ebaa84506c2e;hb=olingo169 [6] >>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4. >>>>>>> gi >>>>>>> t >>>>>>> ;a=tree;f=odata4-lib/odata4-commons-api/src/main/java/org/apache >>>>>>> /o >>>>>>> li >>>>>>> n >>>>>>> go/odata4/commons/api/edm;h=5735ace09587887d86a9f09c9ffdcd624b97 >>>>>>> 52 >>>>>>> 1f >>>>>>> ; >>>>>>> hb=olingo169 [7] >>>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4. >>>>>>> gi >>>>>>> t >>>>>>> ;a=tree;f=odata4-lib/odata4-client-api/src/main/java/org/apache/ >>>>>>> ol >>>>>>> in >>>>>>> g >>>>>>> o/odata4/client/api/edm;h=31d1e59d5b76ba321b93bd68bda675522f9d1a >>>>>>> 8c >>>>>>> ;h >>>>>>> b >>>>>>> =olingo169 >>>>>> [8] >>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4 >>>>>> .g >>>>>> it >>>>>> ; >>>>>> a=blob;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/o >>>>>> li >>>>>> ng >>>>>> o >>>>>> /odata4/commons/api/edm/EdmType.java;h=bee2fa5394774b4ea41a71ee43 >>>>>> 3c >>>>>> f5 >>>>>> d >>>>>> 7366c961c;hb=olingo169 [9] >>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4 >>>>>> .g >>>>>> it >>>>>> ; >>>>>> a=blob;f=odata4-lib/odata4-client-api/src/main/java/org/apache/ol >>>>>> in >>>>>> go >>>>>> / >>>>>> odata4/client/api/edm/v4/EntitySet.java;h=703c0dfa3c23ea66ea88c8f >>>>>> b3 >>>>>> 87 >>>>>> 5 >>>>>> f90962e3a800;hb=olingo169 [10] >>>>>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4 >>>>>> .g >>>>>> it >>>>>> ; >>>>>> a=blob;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/o >>>>>> li >>>>>> ng >>>>>> o >>>>>> /odata4/commons/api/edm/EdmEntitySet.java;h=50dbe0590ff5aa32340ee >>>>>> ee >>>>>> 5d >>>>>> 3 >>>>>> 26844a92f0c91a;hb=olingo169 > >-- >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/ >
