Hi Till, Thank you. You seem to have followed the option 2). I didn't understand how to get along with option 1). I wanted to ask with Ahmed about it and get back. I have no idea when they will release so I asked a question[1] though I didn't get an answer for that.
Thank you. Sincerely, Riyafa [1] https://github.com/Esri/geometry-api-java/issues/140 On 29 July 2017 at 10:58, Till Westmann <[email protected]> wrote: > Hi Riyafa, > > I’ve uploaded another commit to your change [4] that shows what option 2) > would look like. > Please take a look and see what you think. > I think that this could only be a temporary solution. > Do you have an idea, when Esri might publish a new version of the API? > > Cheers, > Till > > [4] https://asterix-gerrit.ics.uci.edu/#/c/1895 > > > On 27 Jul 2017, at 10:13, Mike Carey wrote: > > +1 on option 1 for now, I would say (from afar :-)), until ESRI finishes >> resolving stuff on their end. >> >> Aloha, >> >> Mike >> >> >> On 7/27/17 6:23 AM, Till Westmann wrote: >> >>> Hi, >>> >>> I’m sorry for the late reply on the subject. >>> >>> Generally, Apache-releases are source releases [3] and so adding a >>> precompiled jar without sources would prevent us from being able to >>> release AsterixDB. So we will have to find another solution. >>> >>> A few options that I can think of right now would be to >>> 1) make it an optional dependency and require the user to >>> require/obtain the jar external and to provide it to the platform that >>> they build on or to >>> 2) include the source files in the AsterixDB source repository or to >>> 3) download and build the source as part of the build process. >>> >>> Of these 3 options, I think that 1) is the cleanest option from a >>> licensing perspective, 2) can be managed if we understand the >>> provenance of the source files and 3) seems problematic as we would put >>> a load on a system that provide the source for every build and as we >>> could retrieve use unvetted source code. >>> >>> Thoughts/concerns about these options? >>> Does anybody see other options? >>> >>> Cheers, >>> Till >>> >>> [3] http://www.apache.org/legal/release-policy.html#artifacts >>> >>> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote: >>> >>> Dear all, >>>> >>>> Is there a way to ship a jar file as a dependency for AsterixDB apart >>>> from >>>> the method I have used here[1]. This is because the build of asterix-app >>>> seems to fail[2] when I use the external jar file like this. >>>> Though I am unable to find a connection between the failure and the >>>> dependency it seems I need to assume that it is the cause, because >>>> otherwise if I use the Maven-released version the build passes without >>>> issue. >>>> >>>> Any help would be highly appreciated. >>>> [1] >>>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/aste >>>> rix-om/pom.xml >>>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895 >>>> >>>> On 22 July 2017 at 01:59, Ahmed Eldawy <[email protected]> wrote: >>>> >>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Riyafa Abdul Hameed >>>> Undergraduate, University of Moratuwa >>>> >>>> Email: [email protected] >>>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> >>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> >>>> <http://twitter.com/Riyafa1> >>>> >>> -- Riyafa Abdul Hameed Undergraduate, University of Moratuwa Email: [email protected] Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> <http://twitter.com/Riyafa1>
