Although Esri resolved the issue, their Maven-released version still relies on the incompatible library. We can wait until they release a new version on Maven but this might take a while. To be able to merge the current code, we might need to compile our own JAR file and ship it with the source code. Do you know if this is possible/allowed/recommended in AsterixDB? Is there another preferred way to handle this issue? Keep in mind that, most likely, the summer project will conclude before Esri releases the new version.
Thanks Ahmed On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <[email protected]> wrote: > NICE!!! > > > > On 7/11/17 9:39 AM, Ahmed Eldawy wrote: > >> There's a good news. Riyafa has opened an issue on ESRI Geometry API >> project on Github about the license problem and they made the necessary >> changes to remove the bad dependency. >> https://github.com/Esri/geometry-api-java/issues/135 >> The changes are on their github repository but they are not released yet. >> I >> think we can just continue what we're doing and wait for the new release >> to >> hit Maven repository. >> >> Thanks >> Ahmed >> >> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <[email protected]> wrote: >> >> It sounds like the best option is 4 minus parsing, then, if we can do >>> that. (Which would also address Wail's comments, which could be a killer >>> for big data eventually.) If not, we could go with 2 for the summer as a >>> first step, I guess? (But figuring out the feasibility of 4 would be >>> great...) >>> >>> Cheers, >>> >>> Mike >>> >>> >>> >>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote: >>> >>> It seems that (3) would require modifying the open source Esri API >>>> library >>>> which I don't like. Not only for the overhead of understanding and >>>> modifying the code, but also for deviating from the standard library >>>> which >>>> means we will miss future updates. One of the reasons we chose to use >>>> Esri >>>> API is the hope that it will be well-maintained in the future. >>>> This leaves us with (4). I don't know if it is technically possible to >>>> depend on the standard Esri API without using the non-compliant library >>>> or >>>> not. If this is possible, then we can just use the computational >>>> geometry >>>> (CG) functionality from the library, and provide our own GeoJSON parser. >>>> If >>>> this is not possible, then I would rather consider the use of another >>>> library, e.g., JTS. >>>> >>>> >>>> Thanks >>>> Ahmed >>>> >>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <[email protected]> >>>> wrote: >>>> >>>> I can see from the code that there is a serder steps as such: Asterix >>>> >>>>> Object (binary) --> JSON (String) --> Esri geometry (Java object) --> >>>>> Esri >>>>> geometry (binary). >>>>> I think it would be nice if there is a binary-to-binary conversion >>>>> without >>>>> any deserialization (4th option). >>>>> >>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <[email protected]> wrote: >>>>> >>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.) >>>>> >>>>>> >>>>>> >>>>>> On 6/25/17 5:57 AM, Till Westmann wrote: >>>>>> >>>>>> Hi Riyafa, >>>>>> >>>>>>> I think that the problem is bigger than the failing test. The JSON >>>>>>> license itself is not acceptable for inclusion in an Apache artifact >>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON >>>>>>> functionality be a non-optional part of AsterixDB. >>>>>>> >>>>>>> Here are a few options I see: >>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate download >>>>>>> from a >>>>>>> non-Apache location). >>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each user >>>>>>> would >>>>>>> have to download and install those jars separately - and get >>>>>>> error >>>>>>> messages if the jars are not available). >>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON >>>>>>> library. >>>>>>> 4) Do all of the parsing independently from the ESRI API. >>>>>>> >>>>>>> I’m not sure if 1) is a good option as the extensibility in this part >>>>>>> of the code might not be sufficient to support this option easily. >>>>>>> 2) is technically easier, but it involves an unpleasant user >>>>>>> experience. >>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON >>>>>>> should >>>>>>> be supported by vanilla AsterixDB. >>>>>>> For 3) and 4) we would need to look into the details to see how much >>>>>>> work is required for each of those options and if there are other >>>>>>> legal >>>>>>> hurdles. >>>>>>> >>>>>>> Are there other options? >>>>>>> Other thoughts/concerns? >>>>>>> >>>>>>> Cheers, >>>>>>> Till >>>>>>> >>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x >>>>>>> >>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote: >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> I implemented parse_geojon() function[1] using esri-geometry api[2] >>>>>>>> >>>>>>>> which >>>>>>> >>>>>> is apache-2.0 licensed. But this api uses org.json as a dependency. >>>>>> >>>>>>> org.json is licensed under JSON which causes a license issue in the >>>>>>>> >>>>>>>> code >>>>>>> >>>>>> I >>>>>> >>>>>>> have written[3]. What can I do about this issue? >>>>>>>> >>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838 >>>>>>>> [2]https://github.com/Esri/geometry-api-java >>>>>>>> [3] >>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ >>>>>>>> ration-tests/3290/ >>>>>>>> >>>>>>>> Thank you. >>>>>>>> Yours sincerely, >>>>>>>> Riyafa >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>> >>>>> *Regards,* >>>>> Wail Alkowaileet >>>>> >>>>> >>>>> >> > -- Ahmed Eldawy Assistant Professor http://www.cs.ucr.edu/~eldawy Tel: +1 (951) 827-5654
